Light ROM 1/LIGHT-ROM 1 (Amiga Library Services)(1994).iso/imagine/text/archive.16

Text File | 1994-10-19 | 140.7 KB | 3,420 lines

IMAGINE archive: collected off of [e-mail]

ARCHIVE XVI
Nov. 26 '91 - Dec. 12 '91

If you have questions or problems with this file, email Marvin Landis
at [e-mail]

note: each message seperated by a '##'

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Subject: Upload procedure
Date: Tue, 26 Nov 1991 21:41:53 -0700
From: HURTT CHRISTOPHER MICHAEL <[e-mail]>

    Could you tell what all is involved with putting stuff on hubcap?
It's been pretty stagnant on there so I thought I'd upload a bunch of
junk to try to facilitate some more uploading. I think the new requirements
are stopping alot of people now.
    Thanks!

    Chris

##

Subject: Re: Spring
Date: Tue, 26 Nov 91 19:55:29 CST
From: [e-mail] (Michael Linton)

Mark Thompson <[e-mail]> writes:

> Unless I misunderstand how Imagine does extrusions, extruding a torus is
> absolutely wasteful. 90% of the generated polygons will be inside the
> spring and be totally invisible.

I guess I should have worded it better.  What I ment to say was I know how to
extrude a disk along a spiral path, and I know how to use a torus to make a
spring.

--- (Michael Linton) a user of sys6626, running waffle 1.64
E-mail: [e-mail]
system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8

##

Subject: Re:  places for big animations
Date: Tue, 26 Nov 91 21:46:32 PST
From: [e-mail]

Okay.. here's a place you can send big animations on VHS tape...
Down at Creative Computers' Lawndale, CA store works a salesguy
name of Ed Vincent.  Ed has a tie-in of some kind with the cable-tv
outlet on the Palos Verdes Peninsula (southwest most "hill" in
Los Angeles County), where there are 5 separate cities. (Locals
will know what I'm talking about... nonlocals won't, but it doesn't
make much difference except to say that the PVP is home to some of
the wealthiest neighborhoods in So. Calif if not the entire USA or
the world, for that matter... million dollar homes are considered
cheap/small there. no kiddin..)

At any rate, whilst visiting Creative today, Ed showed me a cardboard
box in which were about 15 VHS tapes that had been sent/given to
him by various Amiga animators.. I saw Heidi Turnipseed's name on
the label on one of them...

Ed's producing an Amiga-animation show for Dimension Cable in
Palos Verdes and these tapes will all be aired.  He's also going
to give them to Paragon Cable which services (I use the term loosely)
the South Bay/Torrance area just to the north of the hill, where
I live :) for airing on that system also.

So those of you interested in this might want to give Ed Vincent
a call at Creative Computers during the day at 213-542-2292 and
talk to him about his project, send him your tapes, etc. You might
as well tell him whereyou read about this and that "Harv sent me"
since I told him I'd try to do some tape recruiting from the
animation wizards who read this list.  I'm getting absolutely nothing
out of this except the chance to see some talented folks (you!)
get aired, and hopefully see the stuff show up on my own local
cable system cuz I'm getting awfully tired of the local CRAP they
air every day.

Regards, Harv

##

Subject: Acceleration & Decceleration with paths
Date: Wed, 27 Nov 91 10:04:30 -0500
From: [e-mail] (Michael B. Comet)

    Thanks for posting that message about how acc/dec works with
imagine.  Helped alot, I fianlly understand how it works.  Unbelievable
what you can do with that. I made a "roller coaster" car (a cube) go
along a valley (path).  It really looks like it's speeding up on the way
down, and slowing down on the way up.

                Thanks,

                    Mike C.
                    [e-mail]


##

Subject: Re: objects following paths
Date: Wed, 27 Nov 91 10:24:50 MST
From: Steve Koren <[e-mail]>

Jim Lange writes:

[ a good description of how path speeds work in Imagine ]

Jim,

Thanks for the great explanation.  This is the sort of detail which I wish
was in the Imagine docs in the first place!  Right now I'm left to
wondering and experimentation, which is often frustrating.

The newsletter that Impulse sent me after I registered said that version
2.0 was supposed to have much more detail in the manuals.  I hope so!

   - steve

##

Subject: Dir Opus Custom gadgets
Date: Wed, 27 Nov 91 13:02:19 est
From: David Tiberio <[e-mail]>

    gadget name:    IFF24_HAM
    function call:    sys:iff/24toHAM

    script file for 24toHAM:

    .key infile/a
    sys:iff/24toPPM <infile> ram:tmp<$$>.ppm
    sys:iff/PPMtoILBM > <infile>.pic ram:tmp<$$>.ppm
    list <infile>.pic NOHEAD
    delete >nil: ram:tmp<$$>.ppm

    /*    note that I am new to PBMPLUS, and I did have problems
        getting my viewers to show any pics converted this way,
        although DPaintIV did load them properly. It may have
        been a problem for my viewers because I have mostly PAL
        24 bit pics                        */

Of course, gadgets can be made for almost any file format, including one
gadget for all formats (I have spare gadgets, so I may as well do it this
way). I also use a GIF24_HAM convertor.

    gadget name:    uuEncode
    function call:    sys:arc/uuencode
                uuencode {f} {sr}        (using mailx)

    gadget name:    uuDecode
    function call:    sys:arc/uudecode {f} {sr}

    Well, silly me...using mailx and just noticed that the uuencode is
    wrong. Here goes one more try:

    gadget name:    uuEncode
    function call:    sys:arc/uuencode.s {f} {sr}

    script for uuencode.s:

    .key <infile>/a
    sys:arc/uuencode ><infile>.uue <infile>


    gadget:     CJPEG
    function call:    sys:iff/IFF2JP {f} {sr}

    script for IFF2JP:

    .key infile/a
    sys:iff/24toPPM <infile> tam:tmp<$$>.ppm
    sys:iff/CJPEG > <infile>.jpg ram:tmp<$$>.ppm
    list <infile>.jpg NOHEAD
    delete >nil: ram:tmp<$$>.ppm

     /*    Today I will decompress the full pbmplus and hopefully
        start writing some really dirty scripts :)        */

David Tiberio
DDD MEN

##

Subject: Dir Opus gadgets
Date: Wed, 27 Nov 91 13:19:06 est
From: David Tiberio <[e-mail]>

  I am now interested in using the PPMscale function and the PPMquant
function for either cropping oversized images or reducing colors to
fit into 640x400 (or overscanned) dynamic hires pics. If anyone knows
how to use these functions, please post.

David Tiberio
DDD MEN

##

Subject: pbmplus info (was Re: Dir Opus gadgets)
Date: Wed, 27 Nov 91 13:54:37 EST
From: Mark Thompson <[e-mail]>

>   I am now interested in using the PPMscale function and the PPMquant
> If anyone knows how to use these functions, please post.

ppmscale has been upadated to pnmscale in the latest release of the tool.
I reccommend you download the doc files when you get the latest version
of pbmplus. It can be found on ab20 in /amiga/graphics/converters/pbmplus
and an update is located in /incoming/amiga/pbmplus. Here are the man pages
for ppmquant and pnmscale:

     NAME
          ppmquant - quantize the colors in a portable pixmap down to
          a specified number

     SYNOPSIS
          ppmquant [-floyd|-fs] ncolors [ppmfile]
          ppmquant [-floyd|-fs] -map mapfile [ppmfile]

     DESCRIPTION
          Reads a portable pixmap as input.  Chooses ncolors colors to
          best represent the image, maps the existing colors to the
          new ones, and writes a portable pixmap as output.

          The quantization method is Heckbert's "median cut".

          Alternately, you can skip the color-choosing step by
          specifying your own set of colors with the -map flag.  The
          mapfile is just a ppm file; it can be any shape, all that
          matters is the colors in it.  For instance, to quantize down
          to the 8-color IBM TTL color set, you might use:
              P3
              8 1
              255
                0   0   0
              255   0   0
                0 255   0
                0   0 255
              255 255   0
              255   0 255
                0 255 255
              255 255 255
          If you want to quantize one pixmap to use the colors in
          another one, just use the second one as the mapfile.  You
          don't have to reduce it down to only one pixel of each
          color, just use it as is.

          The -floyd/-fs flag enables a Floyd-Steinberg error
          diffusion step.  Floyd-Steinberg gives vastly better results
          on images where the unmodified quantization has banding or
          other artifacts, especially when going to a small number of
          colors such as the above IBM set.  However, it does take
          substantially more CPU time, so the default is off.

          All flags can be abbreviated to their shortest unique
          prefix.

     NAME
          pnmscale - scale a portable anymap

     SYNOPSIS
          pnmscale s [pnmfile]
          pnmscale -xsize|-width|-ysize| -height s [pnmfile]
          pnmscale -xscale|-yscale s [pnmfile]
          pnmscale -xscale|-xsize|-width s -yscale|-ysize|-height s [pnmfile]
          pnmscale -xysize x y [pnmfile]

     DESCRIPTION
          Reads a portable anymap as input.  Scales it by the
          specified factor or factors and produces a portable anymap
          as output.  If the input file is in color, the output will
          be too, otherwise it will be grayscale.  You can both
          enlarge (scale factor > 1) and reduce (scale factor < 1).

          You can specify one dimension as a pixel size, and the other
          dimension will be scaled correspondingly.

          You can specify one dimension as a scale, and the other
          dimension will not be scaled.

          You can specify different sizes or scales for each axis.

          Or, you can use the special -xysize flag, which fits the
          image into the specified size without changing the aspect
          ratio.

          All flags can be abbreviated to their shortest unique
          prefix.

          If you enlarge by a factor of 3 or more, you should probably
          add a pnmsmooth step; otherwise, you can see the original
          pixels in the resulting image.

|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|      `       '        Mark Thompson                 CONCURRENT COMPUTER  |
| --==* RADIANT *==--   [e-mail]        Principal Graphics   |
|      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   |
|     Productions       [phone] [phone]   & General Nuisance   |
|                                                                          |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

##

Subject: more model info
Date: Wed, 27 Nov 91 12:47:03 MST
From: Steve Koren <[e-mail]>

There were a few messages here a while back about models.  You could buy
models and use these as a good source for making Imagine objects.

This was a great idea.  I thought of another similar thing also.  Try
getting some model *magazines*.  These things often have detailed
schematic layouts complete with actual scale dimensions, etc.  All you
have to do is transfer the schematic into the detail editor.  The
magazines also have detailed photos of the constructed models with full
markings, etc.  The best part is the price: for the price of a good model,
you can get 3 to 5 magazines.  Alternately, you can check out back issues
from a library for free.

I just borrowed some model railroad magazines from a friend.  They're a
great source of information for building train objects.

   - steve

##

Subject: places for big animations
Date: Tue, 26 Nov 91 14:09:59 EST
From: [e-mail] (Bob Lindabury, SysAdm)

Steve Koren <rutgers!hpmoria.fc.hp.com!koren> writes:

> This brings up an interesting point: what to do with it once I finish it!
> Since this 500 frame animation may be 10 or 15 megabytes, or say 5
> compressed, it seems too large to put on an FTP site unless that site has
> explicitly said it doesn't mind having very large files there.
>
> What do other people do with large animations they make?  I bet there are
> a lot of neat ones out there.  It would be nice to have an easy way to
> share them with other people.

I think most people dump them to tape as soon as possible.  In most
cases, a single anim shouldn't be much longer than 5 seconds.  If you
follow good film-making rules, you should plan your complete
animation in "shots" and then combine them together to produce a
finished "scene".  Any really good animations I've seen have been
pretty much setup and multiple "shots" of <5 seconds in length which
when combined produce a story.  In this way you can setup a rendering
schedule based on the shots in your scenes.

All the pixar stuff is done with multiple camera views and lots of
edits to produce a well rounded story out of long shots, medium
shots, close-ups and reistablishing shots.  When I go out to shoot
film or video I always try to think in terms of a sequence.  The same
*should* be true when going into pre-production on one of your animations.

As far as this helping you for your animation, if you pre-planned it
as I stated above, you can then distribute different scenes from your
animation which when collected would allow the person receiving them
to view the entire animation.

>   - steve

-- Bob

 The Graphics BBS  908/469-0049  "It's better than a sharp stick in the eye!"
 ============================================================================
  InterNet: [e-mail]                | Raven Enterprises
      UUCP: ...rutgers!bobsbox!graphics!bobl      | 25 Raven Avenue
    BitNet: bobl%graphics.rent.com@pucc           | Piscataway, NJ 08854
    Home #: 908/560-7353                          | 908/271-8878

##

Subject: Re: Firecracker 24 - Yet More opinions and such....
Date: Tue, 26 Nov 91 14:27:30 EST
From: [e-mail] (Bob Lindabury, SysAdm)

Mark Thompson <rutgers!westford.ccur.com!mark> writes:

> >     Also, the firecracker WILL work with a toaster.  After seeing
> > toaster paint (and using it for quite a while), I don't know how anyone
> > serious about doing 24 bit grapihcs, retouching, digitizing and such
> > {could get by with it.

Ah, I beg to differ with the above statement.  I tried using the FC24
with the Toaster in the same machine and no-go.  It seems there are
some timing problems as both boards are trying to sync into either
different clocks or signals or something.  Once I removed the
Toaster, the FC worked fine.  Of course, I didn't have the time to
try every variation possible to get the two to peacefully coexist.

> Toaster Paint is truly disturbing to work with and DCTV is too blurry for
> more detailed work. I can't tell you how much I want a good 24bit paint
> program. But since I just bought a color scanner and I have a few more
> purchases to make, it looks like it will be some time till I can afford a
> third display device.

Ha!  An understatement.  It's far more than "disturbing".  It's
basically a last ditch solution if you have no other paint software
that will work in 24-bit. <grin>

Mark, I think you would sincerly like the FC24.  And your purchase of
a scanner is even better, the FC24 supports scanning right in the
Light24 paint package!  I didn't have a chance to try it out but I
think scanning right into paint is a great idea.  Also, Light24
supports several levels of magnification, a spare page, brush effects
and many, many more features.  I was truly impressed with it.  Most
all of the menu commands had keyboard equivilents also.  And alot of
them were the same as Dpaint!  Maybe you should check it out again
and re-evaluate your priorities.  B^)

I think mail-order pricing for the FC24 with Light24 is around
$700.00.

-- Bob

 The Graphics BBS  908/469-0049  "It's better than a sharp stick in the eye!"
 ============================================================================
  InterNet: [e-mail]                | Raven Enterprises
      UUCP: ...rutgers!bobsbox!graphics!bobl      | 25 Raven Avenue
    BitNet: bobl%graphics.rent.com@pucc           | Piscataway, NJ 08854
    Home #: 908/560-7353                          | 908/271-8878

##

Subject: Firecracker 24 and Toaster
Date: Wed, 27 Nov 91 15:15:06 -0500
From: [e-mail] (Michael B. Comet)

    Well, i don't know why the FC24 didn't work with the toaster,
but I have heard that is has worked.  Seem to have a little of each
side of the argument. My guess would be to call impulse and to ask them exactly
what is possible, and what the problems (if any) might be.

            Mike C.
            [e-mail]


##

Subject: Re: Firecracker 24 - Yet More opinions and such....
Date: Wed, 27 Nov 91 16:35:25 EST
From: Mark Thompson <[e-mail]>

Bob Lindabury writes:
> I tried using the FC24
> with the Toaster in the same machine and no-go.  It seems there are
> some timing problems as both boards are trying to sync into either
> different clocks or signals or something.

I just called Impulse and they claim that there is no problem with running
both the Toaster and the FC24 together in the same machine. It could be
a situation where only a very specific configuration and circumstances
cause a problem. I found a few of these kind of problems when beta testing
the first few Toasters.

> the FC24 supports scanning right in the Light24 paint package! Also, Light24
> supports several levels of magnification, a spare page, brush effects
> and many, many more features. Maybe you should check it out again
> and re-evaluate your priorities.  B^) ....I think around $700.00.

Bob you conniving dirt-ball, I'll bet you think its funny making a man
drown in his own drool. I'll bet your sitting behind your terminal right
now cackling away, figuring that I'm out trying to hock my wife's wedding
ring to pay for a FC24, aren't ya. ;-}
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|      `       '        Mark Thompson                 CONCURRENT COMPUTER  |
| --==* RADIANT *==--   [e-mail]        Principal Graphics   |
|      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   |
|     Productions       [phone] [phone]   & General Nuisance   |
|                                                                          |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

##

Subject: FC24
Date: Wed, 27 Nov 91 14:08:31 PST
From: [e-mail] (Steve Worley)

I, too, am fond of the Firecracker. A couple of points that haven't been
brought up:

  You can use as many Firecrackers at once as you like. True, this is
very highend, but think of the nice ability to place one 24 bit
image on top of another, using the genlock-like overlay ability. (and
this is on top of the normal Amiga graphics, too!) You could also
switch from one FC to the other, or even feed them both through an
encoder and to a Toaster for some fun transitions.

The top resolution of the FC24 is 1024 by 482, and to my eyes, the
extra pixels are PLAINLY an improvement over 768 by 482. I would bet
money those people who said the extra resolution was not noticable
were viewing it on a 1084 or 1950 or some other monitor with less than
800 pixels of resolution: of course you won't see any improvement.
For most images, 1K by 482 is overkill, but for renderings, the sharp
edges of objects are helped by the extra resolution.  (Too bad it
couldn't be 1K by 768, though..)

And, of course, the FC works directly with Imagine....

This isn't a commercial, I just really like the FC. I had borrowed one
for a month, and now I'm back suffering with a DCTV.  :-(

And Mark, I'll trade a FC24 for your scanner and videodisk recorder!
In fact, I'll trade two!

-Steve

##

Subject: firecracker thanks plus...
Date: Wed, 27 Nov 91 15:35:14 -0800
From: [e-mail]

thanks to all who commented (and are commenting) on the firecracker !
you all have just about convinced me to forego selling my car and waiting to
buy a rambrant, and  instead buy the firecracker-only two points holding me
back:

i fear someone will come out with a 1024x768 32 bit board for a similar
price...

i want to know why impulse keeps advertising an 8 bit alpha channel if,
according to all accounts i hear, that the board does NOT support it.

(good point steve worley re:resolution and monitor limitations; i definitely
hope to have a decent monitor to take full advantage of the extra pixels,
i never liked the 1084...)

i also think i'll wait to see just how transparently imagine interfaces with
the board in 2.0, can the scanline in any editor feature show in  24 bits ?
that would convince me to buy...:-)

kevin

##

Subject: FC24 raves and review
Date:    Wed, 27 Nov 91 20:06 EST
From: "Marc Rifkin" <[e-mail]>

I was very much interested in the FC24, and when I saw it in action,
I was sold- until I tried the paint program, Light24.  It was horrible.
My last comment, after many others, was boy is this stupid- this was
not objviously designed for artwork, but for hackers to do weak gradient
fills over things they've rendered.
I know this is a little harsh, but could someone verify this or my
other optimistic suspicion that this was the so-called "beta" version
of Light24 that was shipped with early FC24's.
The manual was even worse, being just a few pages stapled together saying
something like "we could spend time writing a good manual, but it's cheaper
to say go experiment and figure how to use it yourself..."

I very much want to be proven wrong on the quality of Light24, so I can
go get a Firecracker.  I really need something that does what it does
for its price.

Marc Rifkin
Integrative Technologies Lab, Penn State University
5F Mitchell Building, University Park, PA 16802
814-863-8062 or for you normal people, [e-mail]
"Say, that's a nice sync!"

##

Subject: Re: Firecracker 24 - Yet More opinions and such....
Date: Wed, 27 Nov 91 20:06:13 EST
From: [e-mail] (Bob Lindabury, SysAdm)

Mark Thompson <rutgers!westford.ccur.com!mark> writes:

> I just called Impulse and they claim that there is no problem with running
> both the Toaster and the FC24 together in the same machine. It could be
> a situation where only a very specific configuration and circumstances
> cause a problem. I found a few of these kind of problems when beta testing
> the first few Toasters.

Ok, fair enough.  To clarify, basically I walked into a retail Amiga
store (Manta is the mail-order side) and asked to see the
Firecracker.  There was no Firecracker in any of the computers but
there was a Toaster in one.  They popped the Firecracker in with the
Toaster and nada on the Firecracker screen.  They popped the Toaster
out and poof, Firecracker output.  That's all I know. <grin>

> Bob you conniving dirt-ball, I'll bet you think its funny making a man
> drown in his own drool. I'll bet your sitting behind your terminal right
> now cackling away, figuring that I'm out trying to hock my wife's wedding
> ring to pay for a FC24, aren't ya. ;-}

Cackle, cackle, cackle..and at Christmas time no less...hehehehe.

See if you can get a demo first.  It may not be as good as it sounds
but I was reasonably impressed (as compared to what else there is in
the 24-bit Amiga market).  One thing that *didn't* impress me (but an
item that left an impression <heh>) was the fact that there was no
bound manual.  Nothing but about 30 pages of copied, typewritten
documentation stapled at the corner (looked like beta docs) for
Light24 and a few pages on the FC24 itself.  Urgh..that infamous
Impulse documentation again...

-- Bob

 The Graphics BBS  908/469-0049  "It's better than a sharp stick in the eye!"
 ============================================================================
  InterNet: [e-mail]                | Raven Enterprises
      UUCP: ...rutgers!bobsbox!graphics!bobl      | 25 Raven Avenue
    BitNet: bobl%graphics.rent.com@pucc           | Piscataway, NJ 08854
    Home #: 908/560-7353                          | 908/271-8878

##

Date: Wed, 27 Nov 91 23:52:03 CST
From: [e-mail] (Colin Stobbe)

Hello,
     The Manitoba Society for Independant Animators has been thinking
about getting some computer hardware for creating 3D animations, and
I was asked to write up a proposal for using an Amiga based system.
I was wondering if people could give me a list of their animation
"dream machines", to give me ideas of what kinds of hardware and
software I should recommend.  Hopefully I can convince them to get
an Amiga setup, since then surely they'll want to hire me as a
consultant/teacher, and I'll get to play with all that nifty stuff
I can't afford.
     Thanks,

          Colin Stobbe
          [e-mail]
             (yes, this isn't my usual address, but I somehow can't
              post with my other one, luckilly I can still read the
              list with it though)



--
[e-mail] (Colin Stobbe)
Draco BBS, Winnipeg, MB [phone]

##

Subject: Re: FC24 raves and review
Date: Thu, 28 Nov 91 10:09:14 EST
From: [e-mail] (John J Humpal)

>
> I was very much interested in the FC24, and when I saw it in action,
> I was sold- until I tried the paint program, Light24.  It was horrible.
> My last comment, after many others, was boy is this stupid- this was
> not objviously designed for artwork, but for hackers to do weak gradient
> fills over things they've rendered.

    I don't think you're being fair to Light24.  Its major problem is
its (lack of) a user interface.  Also, its weakest feature is its gradient
fills -- it can only fill between two colors.  Otherwise, it is actually
a very sophisticated paint program.  The many brush-manipulatin features
are very good, and Light24 is the only 24-bit Amiga paint program that I
know of that will load an Imagine object and render it.

> I know this is a little harsh, but could someone verify this or my
> other optimistic suspicion that this was the so-called "beta" version
> of Light24 that was shipped with early FC24's.

    Is there anything besides a "beta" version of Light24 yet?  I have
been using a friend's FC for the past month, so I don't get any official
news about FC or Light24.

> The manual was even worse, being just a few pages stapled together saying
> something like "we could spend time writing a good manual, but it's cheaper
> to say go experiment and figure how to use it yourself..."

    Must be Impulse company policy ;-)


-John

John J. Humpal -- [e-mail] -- short .sig, std. disclaimer

##

Subject: Firecracker and  Light 24
Date: Thu, 28 Nov 91 11:18:01 -0500
From: [e-mail] (Michael B. Comet)

    First, there seems to be  some concern about the difference in
the 1024 and 768 resolution.   Let me reiterate what i stated a little
better.

    The  1024 image is of course a vetter quality  picture.  And I
am not  viewing it on some cheezy monitor like someone else said.
(Happens to be a panasonic RGB greater than 700 lines or resolution in
case you were wondering (cackle, cackle!)).  Anyways, my point was, if
you are pressed for time, and have limited hard drive space, the 768 is
almost as good, and so is the preffered method in that PARTICULAR case.
Otherwise, i agree, use 1024.

    With regards to light 24, yes the interface isn't that great,
but what it does do is very nice.  As for the manual,  I thought it was
alright, though we all know impulse manuals so far have yot to be very
impressive, (and i happen  to agree, that experimentation is the best
way to learn).  Also, all firecrackers now ship (standard) with a copy
of light 24.  So i don't think it's  a beta version.

                Mike C.
                [e-mail]

##

Subject: FC 24
Date: Fri, 29 Nov 91 11:55:00 +0100
From: Stig Ove Johnsen <[e-mail]>

Now I have read lots of letters, saying lots of nice
things about the FireCracker 24.
BUT, You all seem to live in the states and uses NTSC.
So my question is; Does the FC 24 exist in PAL ?
If not, will it do? (When?)

Hope anyone can help me out here....

Thanks!

PS  This list is great! Keep up the good work everybody!

Stig Ove Johnsen

[e-mail]

// Columbus had a norwegian map

##

Subject:  WOC and TTDDD
Date: Fri, 29 Nov 91 14:38:16 AST
From: Darren Reid <[e-mail]>

       Hi, Caleb.

    I will be at the World of C= in TO as well. I'm one of the
peopl e running C='s Multi-Media booth. I would like very much to attend
your seminar...please tell me how to reserve a spot, and when and where
(yeah, like you have any idea what the set-up will be :) ).
    I had some comments about TTDDD and external objects, but others have
already voiced the same ideas.

    Does anyone want to get together at WOC TO and chat, show off
renderings and trade files? I'm working a booth days, but have lots of leeway
and can leave the booth for hours at a time if needed. I have to work some on
an animation proposal evenings as well, but late nights are my most creative
times anyway. I would love to meet some fellow Imagine users.
    Anyway, chat at ya later...


Shockwave Surfer
[e-mail]

##

Subject: Re: FC24 - Quick Addendum
Date: Sat, 30 Nov 91 12:04:10 PST
From: [e-mail]

 The top resolution of the FC24 is 1024 by 482, and to my eyes, the
> extra pixels are PLAINLY an improvement over 768 by 482. I would bet
> money those people who said the extra resolution was not noticable
> were viewing it on a 1084 or 1950 or some other monitor with less than
> 800 pixels of resolution: of course you won't see any improvement.
> For most images, 1K by 482 is overkill, but for renderings, the sharp
> edges of objects are helped by the extra resolution.  (Too bad it
> couldn't be 1K by 768, though..)

It is very important to note at this point that the resolution of normal
video (NTSC) is 486x582. Yes, the FC24 images at 1024x482 are awful
pretty to look at if you have a monitor that will display the resolution.
Also, if you are going out to film, the added resolution is quite
necessary (actually 2Kx2K is more optimal for film). But from the
discussion on this newsgroup, most people are looking to go out to
video. Rendering at a resolution of 1024x482 would be a waste of time
for video. Not only that but if you do put it out to video from that
resolution, all it will do is blur out the picture somewhat.

Lightwave handles this very nicely. You can render in "Hi Res" which is
roughly normal "video resolution" at 768x480. You can also render in
what is called "AntiAlias" which renders in a virtual sense at "1536x960".
What I mean by this is that if you click on the "Full Frame Size" button,
you will end up with a render image of this resolution. However, if you
don't click on it, it will render at 1536x960, then automatically reduce
this to "video resolution". It uses the extra information that it
generated to anti-alias the image in the resolution reduction.

Of course it would be nice if Imagine did this too, but...  :-).

=========================================================================
Sean Schur                        INTERNET: [e-mail]
Assistant Director Amiga/Media Lab        Compuserve: 70731,1102
Character Animation Department            Plink: OSS259
California Institute of the Arts
=========================================================================

##

Subject: FC24
Date: Sat, 30 Nov 91 20:59:48 CST
From: [e-mail] (Randy Carris)

Bob Lindabury writes:
"I tried using the FC24
with the Toaster in the same machine and no-go.  It seems there are
some timing problems as both boards are trying to sync into either
different clocks or signals or something.  Once I removed the
Toaster, the FC worked fine.  Of course, I didn't have the time to
try every variation possible to get the two to peacefully coexist."

Did you try a two monitor set-up?  If you feed the Amiga RGB to one
monitor (for toaster control etc.) and the FC24 to another monitor,
it should work.  This was what Impulse suggested to me, and it worked
on our machine (A2500).

Has anyone tried out ImageMaster-FC yet?  I have mine on order.  The
list of features makes it sound incredible!  This could well be the
paint/image-processing software solution we have all been waiting
for.  I'll try to do a review of how it works with the FC24 when I
get it.

I hope to get some images upto Hubcap soon.  They are some demo
versions of my 24-bit backgrounds/textures.  They are intended for
video applications (colors adjusted accordingly), but also work great
for brush maps.  The product doesn't yet have a name, but will be
shipping aroud the first of the year and is a collection of 50 736 X
480 X 24 images.  The demos will be in JPEG format.

To Mark T,
How about starting a LightWave mailing list?  I would be extremely
happy to see this.  You, Steve Worley, and many others have been
invaluable in helping many of us learn Imagine, I'm sure you could
offer far more on LightWave.  I don't have the facilities to run the
list, but wiuld you be interested?

Randy Carris
Graphic Imagination Inc.
[e-mail]

##

Subject: auto recognition of Imagine .iob files
Date: Sun, 1 Dec 91 11:31:52 MST
From: Steve Koren <[e-mail]>

Here is a line which users of SKsh can put in their view.magic
file so that the file (view -t) command will recognize Imagine object
files:

IFF Imagine object:OFFSET:0:464f524d........544444444f424a20

You could also add whatever sort of action line you wished:

IFF Imagine object:ACTION:: -- do something here --

  - steve

##

Subject: ImageMaster-FC
Date: Sun, 1 Dec 91 15:28:08 CST
From: [e-mail] (Randy Carris)

Mike C.,

ImageMaster is "a complete 24 bit image system for any model Amiga....24 bit
image processing, composition, analysis and painting system.  It uses special
techniques combined with the Amiga's stock display capabilities to show tou
what your 24 bit image looks like....This is done independently on actual image
data resoloution...it means you can deal with images of any size, without
worrying about the Amiga's screen resolution."  ImageMaster-FC is their module
for display on the FireCracker24.  It is by Black Belt Systems, the creators of
Ham-E the excelent Image Profession for that hardware device.  They finally got
smart and decided that their software  could sell better than their hardware.
I have seen IP and it is quite impressive, IM promises even more.  This could
well be what I've been looking for: Real software to match my display hardware.
The info booklet I have on boasts an incredible number of features, way beyond
ADPro in image processing, miles ahead of Light24 or any other paint program I
have ever seen.  It also does file format conversions such as JPEG (By the way,
they beat ASDG to e market with this).

For more info call1-800-852-6442 and ask for their info release.  Their is so
much info that I cannot even begin to list feature here.  I hope to have it by
the end of the week and will post my impressions of it then.  One of the nice
things is that IM hardware independent.  Black Belt also maintains a BBS and is
paving new ground in terms of customer support and they claim that their manual
is very complete- over 200 pages spiral bound.

Anyway, as you can see, I'm really looking forward to getting my hands on this!
I'll post more later, I will answer any specific questions as best I can.

Randy Carris
Graphic Imagination Inc.

##

Subject: Re: ImageMaster-FC
Date: Fri, 29 Nov 91 15:09:09 EST
From: [e-mail] (John J Humpal)

This sounds very interesting.  Please let us know how you like the
program.  I have seen IP too, and it does have some impressive
image manipulation tools.  If ImageMaster is IP for all Amigas, that
would be great.  I hope Black Belt has cleaned up the interface, though.

ASDG put out a great product (ADPro), but I think the market could
stand a little competition.

-John

John J. Humpal -- [e-mail] -- short .sig, std. disclaimer

##

Subject: IM-FC
Date: Mon, 2 Dec 91 09:02:54 CST
From: [e-mail] (Randy Carris)

I forgot to mention this earlier, ImageMaster also directly loads and saves in
noth Ham-E and DCTV format.  Those of you with DCTV might be interested.  I
forgot the price info before:
Retail is $199, I don't know what the street price is...
The FireCracker24 version must be ordered from Black Belt until the feel the
demand is high enough to ship it to dealers etc.  That's kind of a bummer, but
if it does Half of what they say, it should be well worth it.

Randy Carris
Graphic Imagination Inc.

##

Subject: FC24- Light24
Date:    Mon, 2 Dec 91 11:06 EST
From: "Marc Rifkin" <[e-mail]>

Here's an example of my disappointment:
I selected to pick up a brush and then picked freehand- that let me pick up
a freehand brush.  The same works with circles and rectangles.
Then I tried solid line (connected lines) and it would only pick up a brish
the shape of the first line I drew.  This would be a necessity for picking
up large irregular shapes.

Marc Rifkin
Integrative Technologies Lab, Penn State University
5F Mitchell Building, University Park, PA 16802
814-863-8062 or for you normal people, [e-mail]
"Say, that's a nice GUI!"

##

Subject: Commodore
Date:    Mon, 2 Dec 91 11:15 EST
From: "Marc Rifkin" <[e-mail]>

I know this is just an Imagine list, but you all use Amigas, too, right? B-)

In case you haven't heard, a few Amiga users who owned stock in Commodore went
to the shareholders meeting last week.  When one tried to make a motion that
the meeting be held in the US and not in the Bahamas (where it is held
currently), he was removed by security guards.  BTW, Irving Gould just happens
to have a home in the Bahamas as well as being a member at the country club
where the meeting was held.  Another user tried to bring up how Commodore
needed to keep up with its competitors, but he was just ignored.

I urge all of you to write to Commodore about the  insidious conditions that
exist there that squandering the company's wealth while ignoring problems
arenot in the best interest of you users and the shareholders (who couldn't
afford to go to the Bahamas).  I know this is a common situation in
many companies, but it is also common recently for these companies to
fall or change.  If we generate enough attention, they will find it less
easy to look the other way.

Thanks.

Marc Rifkin , [e-mail]

##

Subject: Re: Imagine Objects
Date: Mon, 2 Dec 91 18:07:39 MST
From: HURTT CHRISTOPHER MICHAEL <[e-mail]>

>
> Hi,
>   does anyone out there have any Star Trek objects for use with Imagine?
>   I would really appreciate it if you do have some (like the new Enterprise)
>   could put them onto Hubcap.
>
>   Thanks.
>
> Sean.
> [e-mail]
>
    Someone uploaded a fairly good Enterprise (from the movies I think)
to a BBS local to me. One fellow made a bunch of maps for it and it looks
really sharp! I also made a little anim of it going into warp using a couple
morphs. I'll upload it to hubcap if someone can explain the new process to me.
One thing about this Enterprise though, it seems to have overly long back
'fins', but this is easily fixed.

    Chris

##

Subject: Cycle-editor & Brush maps
Date: Mon, 2 Dec 91 18:39:37 PST
From: "Jim Lange" <[e-mail]>

I have created a hierarchical robot object in the detail editor and used the
cycle setup option to prepare it for the cycle editor.  I also have a brush
(color) map assigned to the torso of my robot.

The cycle editor converts my object correctly into a cycle object and the stage
editor correctly animates the resulting cycle object, but my brush map does not
appear.

The original grouped object correctly renders with the brushmap, but if I load
the cycle object into the detail editor and check the orientation of the brush
map on the torso object - I find it is oriented totally wrong!

To make matters worse, when I attempt to load the cycle object back into the
cycle editor (the original one saved FROM the cycle editor), Imagine says "Not
a (proper) animated object".  (I recall another user reporting this message
when attempting to load a MODIFIED cycle object).

Are brush maps incompatible with the cycle editor?

has anyone determined what the restrictions are when moving opjects between the
detail and cycle editors?

-------------------------------------------------------------------------------
Jim Lange                [e-mail]
Oracle Corporation            {uunet,apple,hplabs}!oracle!jlange
-------------------------------------------------------------------------------

##

Subject: RE: Cycle Editor and Brush Maps
Date: Tue, 3 Dec 91 11:43:05 -0500
From: [e-mail] (Michael B. Comet)

    My first question is, what version of Imagine are you using.  If
it is 1.1 there should be no problem whith brush maps.  However, 1.0 did
have a problem when brushmapped objects were brought into the cycle
editor.  If you have 1.1, then i don't know what is going wrong.

    Next, I beleive the detail editor is only supposed to load other
detail editor saved objects and forms editor objects, (and obviously i
know realize cycle editor objects.).  However, the detail editor only
saves to the detail editor object type.  Thus, when you load your cycle
object into the detail editor, it is converted back to its original
type=detail.  So, the message from the cycle editor saying it is not a
cycle object is correct.

    Also, the cycle editor (and the command CycleSetup and
CycleShuffle in Ver 1.1 of imagine [in the detail editor]) align the
objects axis so that there Z axis goes from end to end.  This is why
when you add a primitive tube or cone, the Z axis is at the bottom, and
the the Z-axis length is that of the whole object.

    I have found the cycle editor very difficult to use, and so have
seldom used it.  It seems to be easier to morph object repetitively than
to spend alot more time in the cycle editor.  However there is one more
important thing, you should probably add "spacers" such as axis with no
points, in between alll of the objects you are linking together.  This
enables the joints of your object to move in ways that might be needed,
without have to strech them out of proportion.  Also, under 1.1
cyclesetup realigns the axis for you as the cycle editor would so you
can try to fix things in the detail editor before you enter the cycle
editor.  Also in 1.1, after the object has been cyclesetup, you can move
parts in the detail editor to the next postion and then cycleshuffle
(shwoing you how it will come out in the cycle editor), and then save
that as a seperate object.  Now go into the cycle editor and go to the
frame to you want your object to morph to.  (I assume you have already
converted the original cyclesetup object and have loaded it in).  Then
use the pose command, and the editor will take the position of the axis
from the second save(or any object you tell it load with the proper
amount of axis), and it will make that into the current position of the
cycle object.

    Ack.

            Hope this helps,

                Mike C.
                [e-mail]

##

Subject: Cycle-editor & Brush maps
Date: Tue, 3 Dec 91 10:49:51 PST
From: "Jim Lange" <[e-mail]>

I discovered some new information last night regarding my brush map problem.
It seems that the cycle editor takes the brush map and stretches the Z-axis to
the highest point of the cycle object and scales the other dimensions of the
brush map proportionally.

In the case of my robot, the normal orientation of the brush map is in front of
the torso with the the Y-axis extending into the center of the chest at the
robot's right hip.  After the cycle editor converts it, the center of the brush
axis does not move, but the Z-axis is stretched up and in so the end of the
Z-axis touches the top of the robots's head.  The result is that the brush map
is partially inside the torso object and is projected at a downward angle
towards the robot's left thigh.

I tried saving the torso as a separate object and using Assign mode in the
cycle editor to reassign it to the torso, but this had the same result.  (NOTE:
a single base is the parent of the entire group with the torso as a child group
with neck and head as child groups of the torso.)

It may be that the location of my object in the world coordinates has something
to do with it (I believe that (0,0,0) in the detail editor is near the head),
but I'll have to experiment.

Again, any helpful hints would be appreciated.  My work-around plan is to use
pixel 3D to create a 3D version of my bitmap and attach it to the robot.

-------------------------------------------------------------------------------
Jim Lange                [e-mail]
Oracle Corporation            {uunet,apple,hplabs}!oracle!jlange
-------------------------------------------------------------------------------

##

Subject: diffusion grids
Date: Tue, 3 Dec 91 14:13:53 GMT-0500
From: Scott Matthew Krehbiel <[e-mail]>

OK, I have a suggestion for future versions of Imagine:
How about diferent types of filters ( actual ones like
you'd stick on the lens of a camera to put on your scene )

At first I thought this was rather a silly idea, since any
filter that you could stick in front of a camera, you could
emulate in an image processing program ( color values, diffusion
grids, etc. )

Then I realized that some lighting techniques could really be
better achieved with having those funny grids that go over
fluorescent lights, and having cheese cloth to soften a light's
shadows.  An image processing prog. can't really soften only
shadows.

The problem I see with creating objects to actr as these diffusion
grids is that they could take a really long time to render.
Would having prefabricated filter effect objects do teh trick
better?  What do you all think?

Also, does anyone have any suggestions on doing photographic lighting
techniques in Imagine?

Scott Krehbiel

##

Subject: Re: RE: Cycle Editor and Brush Maps
Date: Tue, 3 Dec 91 13:02:54 PST
From: "Jim Lange" <[e-mail]>

In-Reply-To: WRPYR:[e-mail]'s message of 12-03-91 11:43

Michael B. Comet <WRPYR:[e-mail]> writes:

>    My first question is, what version of Imagine are you using.  If
>it is 1.1 there should be no problem whith brush maps.

I am using 1.1, although it is the integer version on an A1000.

>    Next, I beleive the detail editor is only supposed to load other
>detail editor saved objects and forms editor objects, (and obviously i
>know realize cycle editor objects.).  However, the detail editor only
>saves to the detail editor object type.  Thus, when you load your cycle
>object into the detail editor, it is converted back to its original
>type=detail.  So, the message from the cycle editor saying it is not a
>cycle object is correct.

I understand this limitation for objects resaved from the detail editor, but in
my case I was trying to load a cycle object saved from the CYCLE EDITOR.  Since
the cycle I had created had many key frames, I am concerned that the complexity
is causing the problem (I can save simpler cycles).

In general, the cycle editor is working well for the type of animation I am
trying to create.  The problem with morphing in the stage editor is that when
my robot's arm pivots or his head turns, the individual points move in a
straight line between the two objects resulting in distorted body parts
in the intervening frames (shortened arm, flattened head).  For articulated
robot motion, the cycle editor is perfect.  Unfortunately, brush maps just
don't work right.

Since my brush map is primarily text (plus a few lights and bolts), I should be
able to reproduce it fairly well as a 3D object (using pixel 3D 2.0 to
convert).

-------------------------------------------------------------------------------
Jim Lange                [e-mail]
Oracle Corporation            {uunet,apple,hplabs}!oracle!jlange
-------------------------------------------------------------------------------

##

Subject: modeling a body
Date: Tue, 3 Dec 91 21:16:27 EDT
From: [e-mail] (Dan Drake)

Does anyone have any hints about how to go about modeling a human hand.
I have created a robot hand, but it just doesn't cut it.  The only decent
way that I can thibk of is to mold some clay around my finger, pour
some wax in the mold, and then when the wax dries, cut it into peices that can
be measured.  Any mdeling techniques would be appreciated.

dan.

It's fascinating how comple something so simple as a finger is when a computer
tries to model it.

##

Subject: a cheap editing room
Date: Tue, 3 Dec 91 21:33:00 EDT
From: [e-mail] (Dan Drake)

How is this for a 3-d modeling and editing setup:

A3000 25/50         $3000
4 megs    ram        $ 200
200 meg disk            $ 400
FC24                    $ 800
IMAGINE                 $ 180
PERSONAL TBC            $ 500
CCD-V500 cam-corder     $2500
EVO-9800 vcr            $4300
-----------------------------
               $11880

The CCD-V500 is a sony HI-8 cam corder with built in time bas correction and
digital noise reduction.  it also has super VHS outputs, PCM digital stereo
sound, and effects such as dissolves, strobes, flash motion, stop motion,
picture in a still, superimposing, ...
THe sony hi-8 EVO-9800 is a still frame capable VCR with 4 track sound,
time code recording and superimposition, time code insertion, and much more.

This is what I would consider a minimum for professional use.  I wonder
what other platforms can put together?  The cam-corder is a bit gun-ho,
but it would allow you to expand your product line.  You could mix live
video and animation.  Pretty wild.

I just posted this as some neat info that I ran across and investigated a
little.  It's too much for me, but maybe I don't need a new car :-).

dan.

##

Subject: Re: a cheap editing room
Date: Tue, 3 Dec 91 22:26:55 MST
From: Steve Koren <[e-mail]>

> A3000 25/50         $3000

I wonder if for $3000 you'd be better off to get a $1100 A2000 and toss an
'040/4 card into it?  That plus a cheap HD should be around the same
price, and you'd get alot more MFLOPS out of it.

   - steve

##

Subject: Re: a cheap editing room
Date: Wed, 04 Dec 91 11:45:29 EST
From: Mark Thompson <[e-mail]>

Dan Drake writes:
> A3000 25/50             $3000
> 4 megs ram              $ 200
> 200 meg disk            $ 400
> FC24                    $ 800
> IMAGINE                 $ 180
> PERSONAL TBC            $ 500
> CCD-V500 cam-corder     $2500
> EVO-9800 vcr            $4300

I assume you meant Personal SFC rather than TBC. What you need is a single
frame controller, not a time base corrector. One potential problem here is
that the last I heard, the Personal SFC did not support any Hi-8 gear.
Next you will need a good video encoder to convert the FC24 RGB output into
something that you can record. Thats another $1K to $2K. Also, alot more
RAM is highly reccommended. A bigger HD wouldn't hurt either. I found that
the 330 Meg I had was not enough, especially if you plan to render to HD
and later single frame to tape (you will save your VCR heads from a quick
and certain doom this way). Finally, if you wish to mix the live camera
video with the recorded animation, you will need a video switcher and a
TBC/synchronizer. A Toaster and the DPS TBC II would do the trick for
another $3300.
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|      `       '        Mark Thompson                 CONCURRENT COMPUTER  |
| --==* RADIANT *==--   [e-mail]        Principal Graphics   |
|      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   |
|     Productions       [phone] [phone]   & General Nuisance   |
|                                                                          |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

##

Subject: Extrude to path
Date: Wed, 04 Dec 91 11:47:13 -0500
From: [e-mail]

I am trying to use the EXTRUDE function to extrude an object along a path.  I
have had this problem before, but have not used Imagine in ages.  I know it
is a very simple thing to do, but there is something that is confusing about
the way the manual describes it that messes me up every time.  Here is what I
am doing:

   1. add axis (do several times to create axes to define a path).

   2. orient the y axes so that they are pointing in the direction that I
      want to path to follow (not sure about how this works although
      I can pretty much define the path I want by experimentation -- but
      if someone could tell me how this works, it would be helpful.  The manual
      simply says to orient all the y axes in the direction of the path. Does
      that mean that the y axis arrows "------->" need to be on the same
      plane?).

   3. pick all the axes in the path in the order I want the path to follow.

   4. choose sort from the appropriate menu (not sure which).

   5. choose make path from appropriate menu (not sure which).

   6. save path as extpath.obj.


At this point, everything seems like it should be ok, but when I try
to specify extpath.obj (or just extpath) in the EXTRUDE dialogue box,
it says that it cannot find the object.  What am I doing wrong?

Thanks.

Rich Nollman

##

Subject: Re: Extrude to path
Date: Wed, 4 Dec 91 12:22:16 EST
From: [e-mail] (John J Humpal)

A path is a single object consisting or one axis, at least two points
connected by an edge.  Of course, the path can contain any arbitrary
number of points connected by edges.  So, delete all but one of your
axes, and build a path as I described above.  In attributes for your
path, rename the path as PATH, and in the extrude requester, specify
PATH (which is the default) for the extrusion.  All should go well...

-John

John J. Humpal -- [e-mail] -- short .sig, std. disclaimer

##

Subject: Extrude Question
Date: Wed, 04 Dec 91 12:37:23 -0500
From: [e-mail]

I am trying to use the EXTRUDE function to extrude an object along a path.  I
have had this problem before, but have not used Imagine in ages.  I know it
is a very simple thing to do, but there is something that is confusing about
the way the manual describes it that messes me up every time.  Here is what I
am doing:

   1. add axis (do several times to create axes to define a path).

   2. orient the y axes so that they are pointing in the direction that I
      want to path to follow (not sure about how this works although
      I can pretty much define the path I want by experimentation -- but
      if someone could tell me how this works, it would be helpful.  The manual
      simply says to orient all the y axes in the direction of the path. Does
      that mean that the y axis arrows "------->" need to be on the same
      plane?).

   3. pick all the axes in the path in the order I want the path to follow.

   4. choose sort from the appropriate menu (not sure which).

   5. choose make path from appropriate menu (not sure which).

   6. save path as extpath.obj.


At this point, everything seems like it should be ok, but when I try
to specify extpath.obj (or just extpath) in the EXTRUDE dialogue box,
it says that it cannot find the object.  What am I doing wrong?

Thanks.

Rich Nollman

##

Subject: Re: a cheap editing room
Date:    Wed, 4 Dec 91 12:38 EST
From: "Marc Rifkin" <[e-mail]>

In-Reply-To:  mark AT westford.ccur.com -- Wed, 04 Dec 91 11:45:29 EST

In the December issue of .info is a mention of Sony's new EVO-9650,
a HI-8 deck that has an RS232 port and is frame accurate(*). It will
retail for $6000.  Looks like a good Amiga peripheral.

(*)-IMHO (**), no (tape based) VCR is "frame accurate."

(**)- I've always wanted to use "IMHO" somewhere, so there it is.
Marc Rifkin
Integrative Technologies Lab, Penn State University
5F Mitchell Building, University Park, PA 16802
814-863-8062 or for you normal people, [e-mail]
"Say, that's a nice checksum error!"

##

Subject: Re: a cheap editing room
Date: Wed, 04 Dec 91 13:02:24 EST
From: Mark Thompson <[e-mail]>

Marc Rifkin writes:
> In the December issue of .info is a mention of Sony's new EVO-9650,
> a HI-8 deck that has an RS232 port and is frame accurate(*). It will
> retail for $6000.  Looks like a good Amiga peripheral.

I forget where I read about it, but the review I read of the EVO-9650
stated that it was really only suitable for making test animations
and not producing broadcast quality output. Now I remember, it was in
New Media Age.
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|      `       '        Mark Thompson                 CONCURRENT COMPUTER  |
| --==* RADIANT *==--   [e-mail]        Principal Graphics   |
|      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   |
|     Productions       [phone] [phone]   & General Nuisance   |
|                                                                          |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

##

Subject: 24bit maps
Date: Wed, 4 Dec 91 12:31:31 CST
From: [e-mail] (Randy Carris)

Has anyone else had problems with 24bit brushmaps with Imagine 1.1?
When I use a frame painted entirely in Light24, it works fine, but when I use
pictures for another source (such as TIFF images converted to IFF) they do not
render properly in either scanline or trace modes.  They come out as random
noise on the object.  HAM conversions of the same image work fine, and the
24bit one show just fine on the FC24 so I know the files aren't corrupt.
Could it be memory limitations?  I have a 7M system.  I had though that it
would just give me a requester saying not enough RAM for bitmap or something
but it doesn't and the image renders, just not correctly.  Impulse had nothing
constructive to offer me on this.
Anyone?
Randy Carris
Graphic Imagination inc.

##

Subject: Path extrusion
Date: Wed, 4 Dec 91 11:48:48 PST
From: [e-mail] (Steve Worley)

Rich Nollman asks for help extruding along paths.

-How do I extrude to a path? I get an error, or a straight line.

  First, it is important that you use the right type of path. What
"extrude to path" uses is a series of connected line segments to
define the direction the extruded object follows. Extrude does NOT use
the spline paths that are used in the Stage Editor.

When you've created a line segment path, use the attributes requestor
to see the name of the path- you might even want to call it "PATH" as
opposed to "AXIS.5" or whatever it happens to be called already.  Pick
the object or outline you want to extrude, and get to the extrude
requestor. Toggle the extrude to path button, which will unghost the
path name box. Type in the name of the path that you noted before.
Also, make sure you change the "# of segments" box to a number greater
than one!  Your extrusion will be of better quality the higher you set
this, though your object size and complexity will also increase. If
you try to extrude and get an error message, you are using the wrong
type of path- use a line segment path. If you just get a tube that
doesn't follow your path, set the # of segments to something greater
than one.




-What is the difference between line paths and spline paths?

Imagine uses two different types of paths, lines and splines. Line
paths are just an object that consists of a set of points linked by
edges. The order of the points defines the direction of the path. To
make this type of path, it is easiest to add a new axis in the Detail
Editor, then enter "add lines" mode. Whenever you click, a new point
and edge will be added where you're pointing, and you can trace your
path in just a few seconds.  This type of path is used for extruding
along paths as well as the "Grow" F/X.

The other path type is splines.  These paths CANNOT be used in the
Detail Editor, they are for defining routes for objects to move along
in the Stage Editor. Both open and closed paths are available; open
paths are lines that define a route from a starting point to an ending
point; closed paths always start and end at the same place, which is
useful for cyclic motion or looping animation. You can create a new
spline path by selecting "add path." The paths are interactivly
editable in the Stage Editor.




-Steve

[e-mail]

##

Subject: Video & Long graphics
Date: Thu, 5 Dec 91 07:41:51 GMT
From: mit-eddie!bknight.jpr.com!yury (Yury German)

and would like to make a video of them to distribute here...
Well I thought about it and had another Idea... let me know what you
think. I propose we make a Video that we can sell to the publick as well
as get your own unlimited copies. Since I own my own Video Production
company and have an extensive amiga setup with 16 megs of RAM (I love it)
and Plenty of Syquest cartridges lying around (with 2 Syquests drives
sitting in front of me... as well as other hard drives) I can make the
video of all the anims that you can send. Now I only have a SVHS setup
here but we can talk details later. What I am thinking off is that the
people who send in the animations become automatic partners dependant on
the lenght of the animation. With all the profits being shared an equal or
a preditermined amound (thats just an idea). That way we (I) can market
the tape and get a profit while all of us still get a tape without it
costing anything as well as leting the people in the outside world. Those
who are not on the net... and those that do not telecom but read mags
still get a taste of this.

        -= What do you think =- ??????
   _______________________________________________________________________
   !                                                                     !
   ! Yury German                  NET-MAIL:  [e-mail]        !
   ! Blue-Knight Productions      GENIE EMAIL: Blue-Knight               !
   ! [phone]                (Graphic Design and Video Productions) !
   ! [phone]          P.O. Box 985, Queens, New York, 11354  !
   !                                                                     !
   !     ==}----------  Only Amiga makes it Possible  ----------{==      !
   !_____________________________________________________________________!


##

Subject: Brush Mapping questions
Date: Fri, 6 Dec 91 09:19:29 -0500
From: [e-mail] (BRANHAM,JOSEPH FRANKLIN)

I was trying to populate a graveyard with tombstones last night, and
I finally started playing with some mapping features I've never used.

1) How do you use bump (altitude maps)? I created a 1bitplane picture
with my name in large Times letters. The letters were black, and the rest
of the IFF was white. I mapped this onto the front of my tombstone with
the x and z axes bordering the tombstone, and the y-axis instersecting
the front ofthe tombstone.

The object axis of teh tombstone was about 100units, with the tombstone
being about 200x300x75 units.

I've done lots of flat color maps, but I could NOT get my name engraved
into the tombstone.

I tried this seperately as well as with the brush from question #2.

2) I was trying to wrap a good marble brush around my tombstone, since
I like the results better than the algorithmic marble. When using wrap-X,
wrap-z to "shrink-wrap" the brush to cover the front and edges of the stone,
I got severe polar-projection effects on the front.

I've read Mr. Worley's turorial on the subject, but still can't quite
get the hang of this.

Moo
Frank Branham

PS-Will post stills of the skeleton set of Tarot cards that my girlfriend
is rendering as she produces them. So far, they are going to be really neat.

Frank Branham

##

Subject: Re: Brush Mapping questions
Date: Fri, 06 Dec 91 10:50:16 EST
From: Mark Thompson <[e-mail]>

Frank Branham writes:
> I like the results better than the algorithmic marble. When using wrap-X,
> wrap-z to "shrink-wrap" the brush to cover the front and edges of the stone,
> I got severe polar-projection effects on the front.

I have always hated Impulses screwed up terminology and this 'wrap' business
is another fine example. LightWave uses three types of projected image
maps: planar, cylindrical, and spherical, each of which can be with respect
to the x, y, or z axis. I assume that Imagine's wrap-X wrap-Z is equivalent
to LightWave's cylidrical projection using the y axis. If this is the case,
it is not what you would want. You want a planar projection for a flat
surface otherwise you will get map distortion. The problem with projected
mapping is that often it requires you to separate your surfaces so that
they will all be properly projected. A cube for example requires 3 separate
surfaces: planar X axis for the sides, planar Y axis for the top and bottom,
and planar Z axis for front and back. A can requires two surfaces: planar
Y axis for the top and bottom and cylindrical Y axis for the curved sides.
Am I correct in my assumption that Imagine effectively works the same way
but with different terminology?
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|      `       '        Mark Thompson                 CONCURRENT COMPUTER  |
| --==* RADIANT *==--   [e-mail]        Principal Graphics   |
|      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   |
|     Productions       [phone] [phone]   & General Nuisance   |
|                                                                          |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

##

Subject: matching colors against model intructions
Date: Fri, 6 Dec 91 11:18:13 EST
From: [e-mail] (Brian Reynolds)

Someone recently had some questions about the numbering of the colors
on a plastic model's instruction sheet.  I found this article in
alt.models and thought I'd pass it on.  You might want to look at some
of the books on painting models for information about determining the
proper color reproduction.

Brian Reynolds "... a drone from sector 7G."
Fusion Systems Group
[e-mail] -or- ...!uupsi!fsg!reynolds

----- Begin Included Message -----

-- COLOURS.TXT -- Rev.7c -- 1991-12-02 --
Urban Fredriksson, Flyttblocksv., Stockholm, Sweden.
Please send me suggestions for improvements. No copyright claimed.

Sources:
Own paint tins, FS.595a manual, Richard Parker Scale Models
International Sep/91, Mat Irvine SMI Dec/91, colour guide from the
Wentzels hobby shop in Stockholm, Kevin Smith IPMS (UK) Humbrol current
paint range conversion chart, "Colorazioni" by Angelo Falconi.
===================================================================
PoS: = Polly S (new/old) Hu:= Humbrol (new/old)
GS: = Gunze Sanyo        Rev: = Revell
Gloss/matt often substitute for each other
===================================================================
FS 595a    First figure: 1 = gloss, 2 = semigloss, 3 = lusterless
DESIGNATION     NAME AND REASONABLE COLOUR MATCHES

Browns
FS.30117        Earth Red         PoS:PCA829  Hu:186
FS.30118        Hu:142 Field Drab PoS:60
FS.30166        Hu:70 Brick Red PoS:21
FS.30218        USAF Tan
FS.30219        Hu:119 Light Earth/Hu:118 US Tan GS:H310
FS.30266        Middlestone     PoS:PCA818
FS.30277        Hu:187 Sand

Reds
FS.31136        Hu:60 Matt Scarlet (/153 Insignia Red) GS:H327 PoS:20?

Oranges
FS:32473        Hu:82 Orange Lining?

Yellows
FS.33531        Light Brown Yellow  PoS:PCI875 Yellow GS:H313 Hu:121
FS.13538        Hu:188 Crome Yellow GS:H329
FS.33538        Hu:154 Insignia Yellow /Hu:24 Trainer Yellow?
FS.33613        Hu:148 Radome Tan GS:H318
FS.33814        Hu:81 Pale Yellow?

Greens
FS.34079        USAF Dark Green PoS:500814/PCA814  Hu:116  GS:H309
FS.34087        Hu:155(/66) Olive Drab GS:H52 PoS:52?
FS.34092        Green    PoS:50?    Hu:149(/30) Dark green   GS:H302
FS.34097        Hu:105 Marine Green GS:H340
FS.34102        USAF Light green    PoS:500815  Hu:117  GS:H303
FS.34127        Hu:150 Forest Green
FS.34151        Hu:151 Interior Green GS:H58 PoS:PCA802?/821?/833?
FS.34226        Hu:78 Cockpit Green
FS.34227        Hu:120 Light Green GS:H312
FS.34258        Hu:78 Cockpit Green
FS.34424        Hu:90 Matt Beige Green
FS.34554        Hu:90 Beige Green

Blues
FS.15042        Hu:181 Dark Sea Blue
FS.35042        Hu:182 Black Grey
FS.35044        Hu:189 Insignia Blue GS:H326
FS.15050        Hu:190 Blue Angel GS:H328
FS.35109        Blue (Hu:HU15 deleted)
FS.35164        Hu:144 Intermediate Blue GS:H42
FS.35237        Hu:145 Medium Grey GS:H337
FS.35258        Green (Hu:HU17 deleted)
Fs.35414        Blue (Hu:HU14 deleted)
FS.35450        Air Superiority Blue   PoS:PCA800
FS.35622        Light Blue      PoS:PCI877 Hu:122 GS:H314

Grays
FS.36081        Engine Gray Matte   PoS:500014 Grimy Black GS:H301 Hu:32
FS.26118        Semigloss Gunship Gray  As FS.36118
FS.36118        Gunship Grey    PoS:PCA822/500822 Sea Gray  GS:H305 Hu:125
FS.36173        Hu:156 Dark Grey GS:H82
FS.36231        Dark Gull Grey    PoS:PCA824/807? Hu:140 GS:H57
FS.36251        Grey (Hu:HU20 deleted)
FS.26270        Semigloss Ocean Gray  As FS.36270
FS.36270        RAF Ocean Gray  Hu:USN2 GS:H306 Hu:126
FS.36307        Hu:141 Light Sea Grey
FS.36320        Ghost Gray Dark PoS:PCA837 Ghost Gray-DK GS:H307 Hu:128
FS.36321        Dk Gull Grey Hu:140
FS.36373        Hu:87 Steel grey?
FS.36375        Hu:127 US Ghost Grey GS:H308
FS.16440        Light Gull Grey Hu:183 GS:H51
FS.36440        Hu:129 GS:H325 PoS:PCA825?
FS.36463        Hu:146?
FS.16473        Light Aircraft Grey Hu:146 GS:H61
FS.36473        Hu:64 Light grey? PoS:PCA806?
FS.36495        Hu:147 Light Grey GS:H337
FS.36559        Hu:162 Surface grey
FS.36622        Gray    PoS:PCA817 GS:H311 Hu:97 Eggshell

Miscellaneous (blacks, whites, metallics)
FS.17038        Gloss Black Hu:21 GS:H2
FS.27038        Coal Black  Hu:85 GS:H2
FS.37038        Hu:33 Black GS:H12 PoS:10
FS.27040        very slighty dark bluish black Hu:85?
FS.17178        Chrome Silver Hu:191
FS.17875        Gloss White Hu:22 GS:H1
FS.37875        Hu:130 Satin White GS:H11 PoS:11?

Fluoroscent
FS.28915        Hu:192 Blaze (orangeish red, almost dayglo)
-------------------------------------------------------------------
German colours
RLM 02  RLM grau        PoS:PCG83 RLM Gray (02) GS:H70 Hu:92
RLM 61  Dunkelbraun     Dark Brown
RLM 63  Hellgrau        PoS:PCG711 Lt gray (63)
RLM 65  Hellblau        Hu:65 Matt Aircraft Blue GS:H67
RLM 70  Schwarzgrun     PoS:PCG86 Black Grn. (70) Hu:91 GS:H65
RLM 71  Dunkelgrun      PoS:PCG87 Dk. Green (71) Hu:30 GS:H64
RLM 74  Dunkelgrau      PoS:PCG84 Dark Grey (74) GS:H68 Hu:27
RLM 75  Mittelgrau      PoS:PCG707 Medium gray (75) GS:H69
RLM 76  Hellblau        PoS:500088 Light Gray (76)
RLM 78  Himmelblau      Sky Blue
RLM 79  Sandbraun       GS:H66 Hu:62
RLM 80  Olive Grun      Olive Green
RLM 81  Braunviolett    Brown violet
RLM 82  Dunkelgrun      Dark Green
-------------------------------------------------------------------
Imperial Japanese colours
Green A3                PoS:PCJ91 (brownish green, Army)
Green N1                PoS:PCJ92 (blueish green, Navy)
Brown A/N14             PoS:PCJ93 (dark reddish brown, Army/Navy)
Grey A/N2
Mauve N9
Brown N17               Hu:110 GS:H37
Silver A6               Hu:11
===================================================================
Gunze Sangyo
HXXX are water based, and given as "Black numbers in white
boxes". The "Mr Color" range are given as "White numbers in black
boxes", and does not always match!
-------------------------------------------------------------------
H1 Gloss White             Hu:22 White
H2 Gloss Black             Hu:21 Black / Hu:85 coal Black
H3 Gloss Red               Hu:19 Bright Red (see H23) / Rev:31
H4 Gloss Yellow            Hu:69 Yellow
H5 Gloss Blue              Hu:15 Midnight Blue? / Rev:52?
H6 Gloss Green             Hu:3 Brunswick Green
H7 Gloss Brown             Hu:10 Service Brown / Hu:9 Tan
H8 Silver            Hu:11 Silver/ Metalcote Aluminum (satin pale silver grey)
H9 Gold                    Hu:16 Gold
H10 Copper                 Hu:12 Copper
H11 Flat White             Hu:34 Matt White / Hu:130 Satin White
H12 Flat Black             Hu:33 Matt Black / Hu:85 Coal Black
H13 Flat Red               Hu:60 Matt scarlet / Hu:73?
H14 Gloss Orange           Hu:18 Orange
H15 Gloss Bright Blue      Hu:14 French Blue
H16 Yellow Green           Hu:38 Lime / Rev:60
H17 Cocoa Brown (gloss)    Hu:113 Matt Rust (gloss/matt)/Hu:10 Service Brown?
H18 Steel                  Rev:91 Steel
H19 Pink                   Hu:200 Pink
H20 Flat Varnish           Hu:49 Matt Varnish / Rev:2
H21 Off White              Hu:41 Ivory
H22 Gloss Dark grey        Hu:5 Dark Admirality grey
H23 Gloss Shine Red        Hu:19 Bright Red
H24 Orange Yellow
H25 Sky Blue               Hu:48 Mediterranean Blue
H26 Mid Green              Hu:2 Emerald Green / Rev:61
H27 Tan                    Hu:7 Light Buff (gloss?)
H28 Metallic Black         Hu:201 Metallick Black
H29 Salmon Pink (gloss)    Hu:174 Signal Red?
H30 Gloss Varnish          Hu:35 clear poly /Rev:1
H31 White Green (gloss)    Hu:90 Matt Beige Green
H32 Field Grey (gloss)     Hu:67 Matt Tank Grey ?
H33 Russet (gloss)         Hu:133 Brown
H34 Cream Yellow
H35 Cobalt Blue            Rev:53 Blue RAL 5013 / Hu:198 Lufthansa Blue
H36 Dark Green (gloss)     Hu:75 Matt Bronze Green
H37 Wood Brown (gloss)     Hu:110 Matt Natural Wood / Hu:10?
H38 Steel Red              Hu:113 Matt Rust + Silver/ Hu:53 Gunmetal?
H39 Metallic Gloss Purple  Hu:68 Purple
H40 Flat Base              something you mix in paints to make them flat
H41 Pale Green (gloss)     50/50 65 Matt Aircraft Blue/Hu:90 Matt Beige Green
H42 Blue Grey (gloss)      Hu:144 intermediate Blue FS.35164
H43 Wine Red               Hu:20 crimson / Rev:32
H44 Flesh                  Hu:61 Matt Flesh / Rev:35
H45 Light Blue (gloss)     Hu:47 Sea Blue / Rev:50
H46 Emerald Green (gloss)  not quite Hu:2 Emerald Green / Rev:364
H47 Red Brown (gloss?)     Hu:160 German Red Brown?
H48 Field Grey 11          Hu:111 Matt Uniform Grey
H49 Violet (met. gloss)    Hu:68 Gloss Purple with a touch of silver
H50 Lime Green (gloss)     not quite Hu:38 lime
H51 Light Gull Grey        Hu:183 Grey FS.16440 (but more gloss)
H52 Olive drab (semigloss) Hu:155 Matt Olive drab
H53 Neutral Grey           Hu:128 US Compass Grey (but more matt)
H54 Navy Blue (semigloss)  Hu:77 Matt Navy Blue
H55 Midnight Blue (gloss)  Hu:15? / Hu:104 Matt Oxford Blue
H56 Intermediate Blue      Hu:25?,79?,96?,134?,144
H57 Aircraft Grey (gloss)  Hu:140 Matt Gull Grey FS.36231 PoS:PCA824
H58 Interior Green (gloss) Hu:151 Interior Green / Hu:158 Interior Green?
H59 IJN Green (gloss)      very Dark Green
H60 IJA Green (semigloss)  mid-blueish Green
H61 IJN Light Grey (gloss) Hu:146 Aircraft Grey / very Pale Grey, FS.25630?
H62 IJA Light Grey (semigloss)  Matt Light Grey
H63 Metallic Blue-green
H64 RLM Dark Green 71 (semigloss)  Hu:116 US Dark Green / Hu:91 Matt Black Green?
H65 RLM Dark Green 70              Hu:91 Matt Black Green / Rev:363?
H66 RLM Sand Brown 79 (semigloss)  Hu:62 Leather/ Hu:63 Matt Sand w a touch of Orange
H67 RLM Light Blue 65 (semigloss)  Hu:65 Aircraft Blue / Hu:122 Matt Pale Blue
H68 RLM Dark Grey 74 (semigloss)   Hu:27 Matt Sea Grey PoS:PCG84
H69 RLM mid Grey 75                PoS:PCG707
H70 RLM Grey 02 (semigloss)        Hu:92 Matt Iron Grey PoS:PCG83
H71 Middle Stone (semigloss)       Hu:84 Matt Mid Stone
H72 Dark Earth (semigloss)         Hu:29 Matt Dark Earth, WW2 RAF Dark Grey?
H73 Dark Green (semigloss)         Hu:30 Matt Dark Green, WW2 RAF Dark Green?
H74 Sky Duck Egg Green (semigloss) Hu:23 Duck Egg Blue (WW2 sky, correct)
H75 Dark Sea Gray (semigloss)      Hu:27 Matt Sea Grey
H76 Burnt Iron                     Hu:53 gunmetal?
H77 Tyre Black                  Hu:33 Black? Rev:9 Anthracite, ultra-dark grey
H78 Olive Drab 2 (semigloss)       Hu:66 Matt Olive Drab
H79 Sand Yellow (dark) (semigloss) Hu:93 Matt desert
H80 Khaki Green                    Hu:159 Khaki Drab?
H81 Khaki                          Hu:26 Matt Khaki
H82 Dark Grey (semigloss) Hu:156 Matt Dark Grey?
H83 Dark Grey (semigloss) Hu:123 Dark Satin Sea Grey (Japanese naval subjects)
H84 Mahogny (semigloss)   Hu:10 Service Brown / any gloss brown
H85 Sail Colour           Hu:71 Satin oak, cream coloured leather
H86 Red Madder            Dark Reddish-Purple. brighter than Hu:107 WW1 Purple?
H87 Metallic Red          Hu:51 Sunset Red / Rev:399
H88 Metallic Blue         Hu:52 Baltic Blue
H89 Metallic Green        Hu:50 Green mist
H90 Clear Red             transparent colour from Tamiya Acrylic Range or
H91 Clear Yellow                Humbrol "Clear Colour" range
H92 Clear Orange          - '' -
H93 Clear Blue            - '' -
H94 Clear Green           - '' -
H95 Smoke Grey (gloss)    Hu:147 Matt Light Grey (Israeli)
H96 Smoke Blue (gloss)    Pale version of Hu:65 Matt Aircraft Blue (+50% White?)
H97 Fluoroscent Yellow    Hu:194/204 Fluoroscent Saturn Yellow over white base
H98 Fluoroscent Orange    Hu:205/209 Fluoroscent fire Orange over white base
H99 Fluoroscent Pink      Hu:202/207 Fluoroscent Aurora Pink over white base
H100 Fluoroscent Green    Hu:203/208 Fluoroscent Signal Green
H301 FS.36081 Dk Grey     Hu:32 Matt Dark Grey PoS:500014
H302 FS.34092 Dk Green    Hu:149 Matt Dark Green
H303 FS.34102 Dk Green    Hu:117 Matt US Light Green PoS:500815
H304 FS.34087 Olive Drab  Hu:155 Matt Olive Drab
H305 FS.36118 Dk Grey     Hu:125 Satin US Dark Grey PoS:500822
H306 FS.36270 Mid Grey    Hu:126 Satin US Medium Grey
H307 FS.36320 Grey        Hu:128 Satin US Compass Grey PoS:PCA837
H308 FS.36375 Light Grey  Hu:127 Satin US Ghost Grey
H309 FS.34079 Green       Hu:116 Matt US Dark Green PoS:500814
H310 FS.30219 Brown       Hu:119 Matt Light Earth, Israeli AF/Hu:118 Matt US Tan
H311 FS.36622 Grey        Hu:28 / Hu:8 Camouflage Grey?
H312 FS.34227 Green       Hu:120 Matt Light Green, Israeli colour
H313 FS.33531 Brown       Hu:121 Matt Pale Stone, Israeli AF PoS:PCI875
H314 FS.35622 Blue        Hu:122 Matt Pale Blue, Israeli PoS:PCI877
H315 FS.16440 Light Grey  Hu:183 Grey US Navy Light Gull Grey (gloss)
H316                      Hu:22 White
H317                      Hu:140 Gull Grey
H318                      Hu:148 Radome Tan
H319 Light Green (matt)   Hu:117 US Light Green
H320 Dark Green (semigloss) Hu:172 Green / Hu:30 Dark Green?
H321 Light Brown (semigloss)
H322 Cyan Blue (gloss)
H323 Light Blue (gloss)
H324 Light Grey (matt)
H325                 Hu:129 US Gull Grey
H326                 Hu:189 Insignia Blue
H327                 Hu:153 Insignia Red
H328                 Hu:190 Blue Angel
H329                 Hu:188 Chrome Yellow
H330                 Hu:163 Dark Green
H331                 Hu:164 Sea Grey
H332                 Hu:166 Light Aircraft Grey
H333                 Hu:123 Dark Olive
H334                 Hu:167 Barley Grey
H335                 Hu:123 Dark Olive
H336                 Hu:168 Hemp
H337                 Hu:145 Medium Grey PoS:PCA817
H338                 Hu:147 Light Grey
H340                 Hu:105 Marine Green
H341 Mud (weathering)
H342 Oil (gloss) (weathering)
H343 Soot (matt) (weathering)   Hu:33 Black?
H344                            Hu:113 Rust
H345 Rough Gray (matt) (weathering)
H346 Rough Sand (matt (weathering) Hu:93 Desert Yellow
===================================================================


----- End Included Message -----

##

Subject: Re: Brush Mapping questions
Date:    Fri, 6 Dec 91 11:31 EST
From: "Marc Rifkin" <[e-mail]>

In-Reply-To:  mark AT westford.ccur.com -- Fri, 06 Dec 91 10:50:16 EST

>Am I correct in my assumption that Imagine effectively works the same way
>but with different terminology?

Yes- except in Imagine's world, Z is up and Y is depth.
Also, Imagine only has planar (flat) or cylindrical (wrap) X and Z-
1) Does not having a Y present any problems?
2) Since there is no spherical projection, do wrapping X and Z suffice?

Marc Rifkin
Integrative Technologies Lab, Penn State University
5F Mitchell Building, University Park, PA 16802
814-863-8062 or for you normal people, [e-mail]
"Say, that's a nice longword!"

##

Subject: Imagine 2.0
Date: Fri, 6 Dec 91 11:54:15 -0500
From: [e-mail] (BRANHAM,JOSEPH FRANKLIN)

Now that we know more or less what's in it. Does anyone have any idea
on availability. For some reason I didn't get the last newletter, and doubt
I'll get the actual announcement.

(obviously{, I need to contact Impulse and confirm my registration, but
I don't have good access to LD phones during the day.)

For me at least, its probably worth $100 for DCTV support, fog, and X-specs.

##

Subject: Brushmap probs
Date: Fri, 06 Dec 91 12:24:25 EST
From: [e-mail]

Frank asks two questions:

1) Altitude mapping

  With an altitude map, you do indeed use a black and white brushmap.
 However, you will get VASTLY superior results if you blur the sharp
black/white transitions a bit. If they are sudden changes in the brushmap
intensity, the altitude map will work, but the effect takes place over
such a small area you might miss it. Use ADPro to blur the brushmap or
use "smooth" in DPaint.

 Even so, altitude mapping in Imagine 1.1 is broken. It will work for
reflection/refraction, but simple depth shading is nearly nonexistant. This
is a **MAJOR** bug, and has been fixed with great success in Imagine 2.0.

2) Projection problems

  Yep, when you use a brushmap as a wrap/wrap, it gets projected in
strange ways... It's really just an equal-angular projection: think of
the X coordinate of the brush wrapping around the sphere around the
equator from 0 degrees to 360 degrees. The Y coordinate controls the
latitude (whether you are at the equator or North Pole). Mathematically,
X-> theta, Y-> phi in spherical coordinates.

What this means is that a horizontal stripe vertically centered on
your brushmap will be mapped onto the equator of your sphere. A vertical
stripe on the very top of your brushmap will be mapped to a SINGLE point
right at the North pole! The pixels at the vertical center of the brushmap
are STRETCHED.

Solution? Well, there is none. :-) Its the way things are done. Its not
a bug, its a projection method.

In fact, right now I'm working on a program to make a coordinate-remapped
altitude map of a basketball, so when it's projected on a sphere, there
will be NO perspective effect and no seams, even at the equator. Very
interesting....


Good luck, Frank.

-Steve

---------------------------------------------------------------------------
Steve Worley                                        [e-mail]
---------------------------------------------------------------------------

##

Subject: Mapping terminology.
Date: Fri, 06 Dec 91 12:31:31 EST
From: [e-mail]

Just like Lightwave, Imagine supports ALL THREE projection methods.

Flat X Flat Z  - Flat mapping (rectilinear coordinates)
Wrap X Flat Z  - cylindrical mapping (cylindrical coordinates, theta=atan(x,y)
Flat X Wrap Z  - cylindrical mapping (cylindrical coordinates, theta=atan(z,y)
Wrap X Wrap Z  - spherical mapping (spherical coordinates, theta=atan(x,y)
                                                   phi=atan (z,sqrt(x^2+y^2))

-Steve

---------------------------------------------------------------------------
Steve Worley                                        [e-mail]
---------------------------------------------------------------------------

##

Subject: Re: Imagine 2.0
Date: Fri, 6 Dec 91 09:23:54 PST
From: Mark Davis <[e-mail]>

During Wednesday nights chat on Portal the folks at Impulse
stated that it should be ready in approx 15 days and they are
taking orders.  The upgrade cost is $100.00US.  I called and
verified this.

mark davis
[e-mail]

##

Subject: re: Imagine 2.0
Date: Fri, 6 Dec 91 09:28:56 PST
From: Mark Davis <[e-mail]>

I should clarify my previous posting.  It was stated that the
next newsletter mailing would be in about 2 weeks.  I verified
that they are taking orders and the cost is $100.00US.

mark

##

Subject: Re:  Brushmap probs
Date: Fri, 6 Dec 91 14:12:36 -0500
From: [e-mail] (BRANHAM,JOSEPH FRANKLIN)

1) Altitude Mapping

Referring to the major bug, I interpret this as meaning that I can only
see the altitude mapping if my tombstone is clear or reflective?

Moo
and thanks for the articles
Frank Branham

##

Subject: re: Brushmap probs
Date: Fri, 6 Dec 91 13:05:52 MST
From: Steve Koren <[e-mail]>

[ some stuff about brushmaps ]

Here's the problem I have with brushmaps.

Lets say I have an object to which I assign a brushmap to a flat surface
using a flat mapping for X and Z.  The results turn out just as I expect.

Now, if I go into the detail editor and _resize_ the object, all is lost.
What happens is this: the brushmap is resized properly, but not relocated
properly.  Say the old brushmap size was (10,10,10).  When I double the
size of the object, the new brushmap size becomes (20,20,20), just as I'd
expect.  (In other words, the surface the brushmap was on is now twice as
big, so the brushmap has to be twice as big also if it is to cover the
surface entirely as it did before).  However, the brushmap position
doesn't move properly, so it is no longer on the surface of the object
(since doubling the size of the object moved the surfaces).  So whenever I
resize an object in the detail editor, I have to go in manually and
re-adjust the positions of all the brushmaps.  That can take quite a while
if there are a lot of them.  Moral: don't resize objects to which you have
assigned many brushmaps.

(BTW, this is with Imagine 1.1.  I don't know if 2.0 fixes this).

With texture maps, something different happens which can be either a bug
or a feature depending on your point of view.  Lets say you have a 10x10
grid texture assigned to an object.  If you resize it (in the stage
editor, not the detail editor as above), the grid is still 10x10 but the
object is now twice as big.  So you'll have twice as many grid units on
the object.  Why can this be a feature?  Recently I made a train track
object.  If I had made each individual tie a separate object, it would
have taken too much memory if I needed hundreds of ties.  Instead, I made
one large surface and assigned a wood texture to it.  Then I made
transparent stripes on that, so the result was the same as if I had a
bunch of separate objects for the ties.  This allows me to resize the
object in the stage editor, and the ties will stay the same size.  If I
want to make my track twice as long, I get twice as man ties, which is the
exact result I want.  I hope they don't "fix" that for 2.0, or if they do,
I hope they they provide an option to get the old behavior back.

    - steve

##

Subject: Imagine's phong interpolation
Date: Fri, 6 Dec 91 10:53 PST
From: [e-mail] (Scott Busse)

I have been having a great deal of trouble getting Imagine to adequately smooth
the facets off round surfaces. Example a cylinder with only 12 sides. In any
one static frame, the facets are barely visable, and the smoothing can be
tweaked (through light position and intensity modification) to make it look
good. But in rendering animated sequences(in 24bit, BTW) the rounded surfaces
in my scene are flickering wildly with inadequately smoothed facets.
  I concede that I may have some gap in my lighting techniques, and would
surely welcome someone's help here, but note that I have been doing this for
quite some time (since the dawn of the Amiga) and work on a Symbolics without
having any problems of this type.
  In my opinion, Imagine's smoothing function is totally inadequate. I'm
curious that nobody else ever comments on this. I have noticed that there's
often a *big* difference between the way Imagine renders a scene in HAM mode
and how it renders the same scene in 24bit. I have found gross changes in the
lighting intensity between the two, similar to the problems I used to get in
Sculpt4D when a light was placed in the camera's view, causing the lights to
fall drastically in intensity. On the other hand, when rendering a cube that
has smoothing turned on in Sculpt, it would do a fine job of smoothing the
edges, even that 90 degree angle  in between them. But in Imagine, as I have
pointed out, many things are riddled with flat surfaces that should have been
smoothed over.
  Doesn't anyone else have this problem? I'd like to see alot more time spent
by the programmers on beefing up the renderer, instead of the feature madness
that is currently going on.
  But in case my problem is: "All you have to do is turn on the super-phong
button!", or some other simple thing, then...never mind :)
(and thanks for the tip!)
--
* Scott Busse                  O    O   O_     _      ___ .....
* email:                      |||  /|\  /\   O/\_     /         O    )=|
* CIS 73040,2114               l   | |   |\    / \   /\                _\
* [e-mail]                  Live Long and Animate... \

##

Subject: re: Brushmap probs
Date: Fri, 6 Dec 91 17:42:09 PST
From: "Jim Lange" <[e-mail]>

Regarding Steve Koren's comments about texture maps not scaling:

>With texture maps, something different happens which can be either a bug or a
>feature depending on your point of view.  Lets say you have a 10x10 grid
>texture assigned to an object.  If you resize it (in the stage editor, not the
>detail editor as above), the grid is still 10x10 but the object is now twice
>as big.  So you'll have twice as many grid units on the object.  Why can this
>be a feature?  (explanation follows)

I've thought about this in combination with Steve Worley's idea for
implementing "contour" mapping (or an approximation thereof).  To refresh your
memory, here is an excerpt from Steve's original post (several months ago):

>Here's my idea: You are given the option to designate SURROGATE
>objects to define the attributes, textures, and brushmaps. These
>surrogate objects must have the same number of points and the same
>topology as the "real" object. Most likely the surrogate would be the
>virgin copy of your object before you dent, wrinkle, fold, and explode
>it.
>
>What happens is that when your dented object is rendered, the
>attributes defined by the surrogate object are used, NOT the
>attributes of the dented version. A ray striking a certain face on the
>dented can would get its attributes from the corresponding face on the
>REFERENCE object. The exact position on the struck face can be
>interpolated on the reference object (simple 3 point linear
>interpolation) and the color, reflectivity, and transparency can be
>determined. This, if a ray strikes the center of a dent, Imagine looks
>at the same face on the undented reference object. The brush map(s) and
>texture(s) that color the point on the REFERENCE object are applied to
>the real object. Voila! The dented area is now properly colored.

The proper implementation of Steve's idea (in Imagine 2.1 perhaps) could solve
the map/texture resizing problem (and by solve, I mean provide an option for
object resizing).  The current challenge with resizing algorithmic textures is
controlling which of the numeric parameters to scale.  Either the the texture
code must tell the resize routine which parameters are to be scaled or all
parameters must be expressed as percents or numbers which are relative to the
object size (an thus don't need to be scaled).  This problem is avoided
altogether if reference objects are used.  Here is how it could be implemented:

When defining an object that you plan to deform (the REFERENCE object in Steve
Worley's example) you click on a button in the attributes requester called
'Freeze' that will take a snapshot of the object and store it internally with
the object as the reference object.  Then nothing you do to the object from
that point on (including distorting or SCALING) will affect the frozen version.
Thus texture and brush maps would automatically scale with the object by virtue
of the fact that the frozen version is not changing!  If you don't want the
brush/texture map to scale (as in Steve Koren's case), just don't freeze it.

A menu option could allow you to switch the displayed object in the detail
editor to the frozen version for editing purposes if you need to change it.
Thus every object would have two versions, one for surface
mapping/color/texture and one for shape and shading, and each could be
independently edited.  When points, edges, and faces are added to an object,
they could be added to both objects or perhaps only the "live" version (it
wouldn't make sense to add points to a frozen object if they did not also exist
on the live object).

Internally, it would only be necessary to store the location of the points for
the frozen object since since all the edges and faces should be the same.  In
other words, each point would have an extra (optional) set of coordinates to
identify the location of the frozen version of that point.

Another option would allow you to load in any other object to serve as the
frozen version.  The "natural" order of the points in the object would
determine how they are associated.  The two objects would not even have to have
the same number of points.  If the live version has more points, the unmatched
points just get frozen at their current location.  If the frozen version has
more points, the extra ones are just ignored.  Some really interesting effects
could be achieved by mapping an image onto one shape, but using a completely
different shape for the visible contours.  The forms editor would be
particularly useful here since it is easy to generate objects with matching
points that have very different shapes.

This feature is at the top of my list for the "next" version of Imagine.  It
would be relatively easy to implement, provide incredible power, yet have
little impact on rendering time and would not add complexity to the detail
editor for users who don't access it.

-------------------------------------------------------------------------------
Jim Lange                [e-mail] Oracle
Corporation            {uunet,apple,hplabs}!oracle!jlange
-------------------------------------------------------------------------------

##

Subject: Extruding To Path - in case you didn't know...
Date: Sat, 07 Dec 91 08:43:47 -0500
From: [e-mail]

This is probably obvious to many on the list, but I am posting this in
case there are some out there like me, who get stuck because they rely
on the manual.

I recently posted a question about the EXTRUDE (TO PATH) function.  I
got several answers, but nothing seemed to work so I called Impulse.

The manual is COMPLETELY WRONG.  The person I spoke to stopped me
before I could get a couple of sentences out describing my procedure.
MAKE PATH does not create paths for the EXTRUDE function (or any other
function).  You simply create ONE axis (using the ADD function) in the
Detail Editor.  Then you add lines to define your path (as you would
to define any object).  It was suggested to me to change the attribute
name of the path just created to "PATH" (the default pathname for the
path in EXTRUDE TO PATH) in the ATTRIBUTES window (using F7 key). Then
you select your object, orient in the appropriate manner in relation
to the path (my next question - how exactly does Imagine extrude the
object to the path) and extrude away.  I guess MAKE PATH (in the
Detail Editor) is for creating paths for objects in the Stage Editor.
It just gives you more flexibility than path creation in the Stage
Editor.

Now for my next question.  I am confused about how to orient the
object I am extruding.  For example, if I want to extrude a disk (a
primitive) in an S-curve and I wanted a very smooth curve, how do I
align the Y-axes of both the path and the disk?  Also, do I have to
create a path with ALOT of points to make the curve smooth or can I do
it using the number of sections parameter (many sections, smoother
path?). I tried specifying as many as 50 sections, but Imagine seems to
ignore my input.  It just creates the object with bend sections that
correspond to points in the path.

And it does two very annoying things.  The extrude is fine until it gets to
the end of the path, then it flattens out (in the last section) and extends
back to the beginning of the path so I get an final object that looks
something like this:


                         /''''''''''\
                        /            \          \
                       /              \        / \ <--- flat section
                      |    |''''''|    |     / /  \
                      |    |      |    |   /  /|   \
                      |    |      |    | /  /  |    |
                      |    |      |    /  /    |    |
                      |    |      |  /  /  <---------- connects back to start
                      |    |      |/  /|       |    |    of path
                      |    |     /  /  |       |    |
                      |    |   /  /    |       |    |
                      |    |/   / |    |       |    |
                      |    |  /   |    |.......|    |
                      |     /      \                |
                       ----         \               |
                                     \............./

Rich

##

Subject: phong shadig
Date: Sat, 7 Dec 91 12:56:46 GMT-0500
From: Scott Matthew Krehbiel <[e-mail]>

Recently, someone said that they didn't like Imagine's renderings in
12-bit mode, and that it doesn't do a good job of smoothing in 12-bit.

I suggest rendering to 24-bit mode and let AdPro or some good image
processing program do the conversions, since you get what you pay for,
and in a ray-tracing program, you're kind-of getting a bulk package.

Scott Krehbiel

##

Subject: Re: Extruding To Path - in case you didn't know...
Date: Sat, 7 Dec 91 14:10:02 MST
From: HURTT CHRISTOPHER MICHAEL <[e-mail]>

> Now for my next question.  I am confused about how to orient the
> object I am extruding.  For example, if I want to extrude a disk (a
> primitive) in an S-curve and I wanted a very smooth curve, how do I
> align the Y-axes of both the path and the disk?  Also, do I have to
> create a path with ALOT of points to make the curve smooth or can I do

    I believe so. I've recently made an S in a similar manner. To make
the path for it I used the disk primative. I rotated all the points in it
(not the axis) 90 degrees on the X. Then I went in and deleted about 1/3 of the
points so I had 1/2 an S. Copied it into the buffer. Pasted down a new 1/2 S
and move it accordingly so that it they lined up together in the middle.
Then I joined the two together as one path and performing a Merge is a good
idea since there should be two points where the paths line up in the middle. The
trick is to make sure that the points are 'created' in the way you want. An
easy way to tell (at least on 68000s) is to watch as the path is redrawn. The
direction that it takes when drawing is the order of which the points will
be visited along your path. At least I'm pretty sure. This may be part of your
other problem.
    The reason I say rotate the points above is to help with keeping my
Y's straight. When extruding I always rotate all the points in an object
rather than the object, so it stays at default. Easier for me to then just
make the path with a defualt axis in the top window and not have to worry
about how I have my two Y's lined up.
    If I'm unclear on this mail me and I'll give you it step-by-step. Good
luck!

    Chris

##

Subject: Videotape
Date: Sat, 7 Dec 91 07:42:24 GMT
From: mit-eddie!bknight.jpr.com!yury (Yury German)

Wow that was fast... Well I see that I got a few responces from everyone
about the VIDEOTAPE... why don't we set it up with direct mailing.
If you are interested in this project EMAIL me at [e-mail]
I guess I will mail the letters to everyone... I have an Idea about this
when we work it out. I will mail you (a contract and we can get it going
that way) but first lets talk !!!!

##

Subject: animation trouble
Date: Sun, 8 Dec 91 18:58:01 EST
From: [e-mail] (Ramin Taraz)

Hi everybody,

I have asked this once before but I feel that I have ask it again!!!

I am trying to make a simple animation but the outputed pictures have different
palletes.  I don't know why its happening to me,  I have tried low res and ham
and I get different pallete for pictures.  I remember once imagine asked me
if I wanted to lock the pallete, but it never asked me that again.

Does anybody else have this problem with palletes?  Somebody told me to use
another program to lock all the palletes but that is time consuming,  after
all, it imagine should do that.  one of my friends made an animation and
it came out fine!

I dont know, maybe imagine doesn't like me!  it is really sickning to wait
a day or two for a traced/ 8 frame animation and see that the output is
terrible!

How do you lock the pallete?

thanx again
rtaraz

##

Subject: anim palettes
Date: Sun, 8 Dec 91 19:30:09 GMT-0500
From: Scott Matthew Krehbiel <[e-mail]>

I have also had trouble with schizophrenic palletes in imagine.
I don't remember anything about a lock pallette option, but
what's up?  Anybody using Imagine on a 68000?
thanks
Scott krehbiel
[e-mail]

##

Subject: Hinge?
Date: Sun, 08 Dec 91 19:22:20 CST
From: [e-mail] (Michael Linton)

What does the funtion hinge do in the action editor?  As usual the manual
helped me very little.  From what I can tell it acts like a hinge, seems
logical, but I tryed it and it didn't seem to do anything.  Any input
would be appreciated.  Thanks.

--- (Michael Linton) a user of sys6626, running waffle 1.64
E-mail: [e-mail]
system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8

##

Subject: Re: anim palettes
Date: Sun, 8 Dec 91 19:29:43 PST
From: Daryl T. Bartley <[e-mail]>

Yeah, I'm one of the nutters using Imagine on a 68000. Why do you ask? Are
there more bugs due to the 68000? The palette can't be one of them, because
the problem cropped up on two 68030 systems I was using, a 3000 and a 2500..

Daryl Bartley
[e-mail]

##

Subject: 68000 bugs?
Date: Sun, 8 Dec 91 23:31:01 GMT-0500
From: Scott Matthew Krehbiel <[e-mail]>

Well, I'm running Imagine on a 68000 sys, and can't get any Transparency,
brush mapping.  A friend created a trans-mapped object and rendered it,
and it looked great coming from his 68030, but when I tried in
non floating point Imagine, I got just a plain colormap.

Has anyone been able to do Transparency mapping on a 68000?
I guess that's the question I should have asked.

And by the way, yes I am working in trace mode, not scanline.

Thanks - Scott Krehbiel - [e-mail]

##

Subject: Re: animation trouble
Date: Mon, 9 Dec 91 8:01:43 MST
From: Steve Koren <[e-mail]>

> I am trying to make a simple animation but the outputed pictures have
> different palletes.  I don't know why its happening to me, I have tried
> low res and ham and I get different pallete for pictures.  I remember
> once imagine asked me if I wanted to lock the pallete, but it never
> asked me that again.

> a day or two for a traced/ 8 frame animation and see that the output is
> terrible!

> How do you lock the pallete?

I don't think you can lock the palette from within Imagine.  But I would
tend to wonder whether it is really necessary.  If you render a bunch of
frames with different pallettes, you can animate them just fine given two
requirements:

  * The program you use to build animations must be able to put CMAP
    chunks in the anim file.

  * The program you use for playing the animation must understand CMAP
    chunks.

There are PD programs which meet both of those criteria.  Check out the
"BuildAnim" program which comes with the BigAnim program.  It will
correctly build an animation file from stills with different palettes.
Also, RTAP will allow you to play these animations back correctly.
Several other PD animation players will as well.

Good luck,

    - steve

##

Subject: Object instances in Imagine
Date: Mon, 9 Dec 91 8:28:29 MST
From: Steve Koren <[e-mail]>

Here is an idea I had to improve Imagine.  I am planning to send it to
Impulse as a suggestion, but I thought I'd run it by the mailing list
first to see if 1) someone has already suggested it, or 2) Imagine 2.0
will do it, or 3) Imagine 1.1 already does and I'm just missing it.

Lets say that you build a house object.  You have put alot of work into
this house object, and it is very detailed, with lots of brushmaps,
textures, and many polygons.  It ends up at over 120K when you save it on
disk, not including the brushmaps.

Now, lets say that you wish to make a city of these houses.  In the stage
editor, you load a bunch of them in.  You quickly run out of memory.  Why?
Because the stage editor loads the > entire object description < for each
and every house.  They are all separate.  So you are loading 200 polygons
for the first house, 200 for the second, etc.  This obviously gets
expensive quickly.

Well, what is the alternative?  Lets say that Imagine allowed you make
"Virtual Copies" of the house object.  The virtual copy, or "instance",
would share the same vertex, edge, polygon, brushmap, attribute, etc.,
data as the original.  There would be only one copy of this stuff.  Each
instance would simply point to the same description.

What good is it then?  Well, each instance would store only enough
information to have a new position, orientation, and size.  Basically, the
only properties of an instance are those which you can change by the
"transformation" requestor.  All other things are properties of objects.

This would allow us to load our 120Kb house, and make a second copy of it
in a different position.  The second copy would only cost around 128
bytes.  (Or just enough to store the structures Imagine uses for the
position and orientation.  I don't know if this is exactly 128 bytes, but
I'll assume it is for sake of example).  Any additional copies would also
cost 128 bytes.

If we wish to make 100 copies of our house, the memory requirements to
store the object descriptions would fall from (120Kb * 100) = 12 mb, all
the way to (120 Kb + .125 kb * 100) = 0.132 mb.  Big difference, eh?

Right now, Imagine is not very frugal with memory.  This could help alot.
It could also help when design one "object".  For example, if I make a
"railing" object and copy it 50 times to form a fence, I could use
instances for that, even though the result will be grouped into one
object.  The other advantage comes when you want to change the instance's
attributes.  If I want to make my fence blue instead of green, I can pick
any instance and change it.  The change will then be reflected in all the
copies of the instance, since the surface attributes are stored only once
in common for all of them.  This is better than having to call up the
"attributes" requester 50 times for each fence rail.

Does anyone know if Imagine 2.0 is supposed to allow this?  If not, I will
send the idea in to Impulse.  It is definately technically sound, as it is
a time-proven technique which has been employed by other 3D rendering
programs.  The only additional bit of data needed internally by Imagine is
a reference count stored in the object of the number of instances
currently referencing this object description.  This is necessary so that
the program can tell when the object data can be freed because is no
longer referenced by any instance.

This could help a lot I think.  Right now I routinely run out of memory
when building things on my 5 mb system, and I expect to run out when I
upgrade to 9 mb as well.  I could build much larger models with this
feature.

   - steve

##

Subject: Re: Imagine & Palette Locking
Date: Mon, 9 Dec 91 12:02:40 -0500
From: [e-mail] (Michael B. Comet)

    With regards to palete locking, i beleive it asks you that when
you choose ot make an animation in the ANIM formt, not the Imagine
Format.  However, I recall reading (i beleive in some amiga mag) that
even though it prompted you for that, it doesn't work (ie: it is a bvug,
and/or never worked properly on ANY machine).  Thus unless 2.0 has
coreected this, you will HAVE to use an external program to enable this
feature.  I would reccomend attmepting to reach Impulse to see if this
has been corrected in the future version.


                    Mike C.
                    [e-mail]

##

Subject: Re: Hinge motion in Imagine
Date: Mon, 9 Dec 91 12:20:13 -0500
From: [e-mail] (Michael B. Comet)

    Okay, this one had me puzzled for quite some time too before I
finally figured it out.  The best way to do this is to set up a small
anim (just in the stage editor, no need for real rendering) without
hinge, and then after viewing, adding the hinge and makeing it again.

    Here's how it works.  I would set up a primitive sphere in the
center of the animation with the camera aiming toward i, or tracking to
it.  Make sure there is plenty of room around the edges since there will
be another object "orbiting it".  Now add another object, perhaps
aother sphere smaller so we can see it easily.  Now (i forgot to mention
you should have set up about 15-30 frames), go to frame one and position
the smaller object somewhere around the sphere where the camera can see
it.  By defualt, its position will be remembered.  Now go to the last
frame and position it closer to the sphere and in a diferent part of the
screen.  (ie frame one might be in the lower left part of the screen and
the last frame in the upper right.)

    Okay, now before you make your animation don't forget to either
extend the objects timeline manualy in the action editor (v1.0) or use
the Right Amiga-7 key. (v1.1).

    Now make your animation.  What you will see is the object
traveling in a STRAIGHT path from its starting point to its ending
point.  It may even be going through the larger object.

    Okay, now the easy part: Go into the action editor and add a
time line for the hinge portion of the smaller object.  Make sure it
extends for all frames.  (ie 1->ending frame)   Also, (very important)
type in the name of the larger object in the requestor that appears as
it is shown in the list of the action editor.

    Let me explain what this does.  Basically, the small object
traveled in a straight path.  What we would like to do, would be to have
it ARC around another object, (in this case the larger sphere), As it
gets closer, the arc length will decrease.  You could kind of imagine
this as a small meteor slowly getting pulled in by gravity to the larger
object.  So, now we tell it to hinge to the larger object, (it doesn't
even have to be an object, it could just be an axis) and it will use the
location of the larger objects axis to determine the path for the
smaller one.  It is important to note that your object will always start
and end in the exact location you set it to, but the path it take will
change.

    So, now click on okay, and go back to the stage editor and
render your small little test anim.  You should now see the object move
around the sphere in a nice smooth arc.  If not try setting up different
start end points to get a better camera angle.

    This feature is very useful for making things travel around
planets and stuff that you don't go in a perfect circle.  One thing I
did with it was to make a planet, and then some 3-D text, and had it fly
around from side to front as in the Universal Picures Logo.  I didn't
need to make a path, all i did was set up the start/end points, hinged
the logo to the planet, and it arced smoothly for me.


            Hope this helps,

                    Mike C.
                    [e-mail]

##

Subject: Re: Extruding To Path - in case you didn't know...
Date: Mon, 9 Dec 91 12:36:32 EST
From: [e-mail] (John J Humpal)

>
> Now for my next question.  I am confused about how to orient the
> object I am extruding.  For example, if I want to extrude a disk (a
> primitive) in an S-curve and I wanted a very smooth curve, how do I
> align the Y-axes of both the path and the disk?  Also, do I have to
> create a path with ALOT of points to make the curve smooth or can I do
> it using the number of sections parameter (many sections, smoother
> path?). I tried specifying as many as 50 sections, but Imagine seems to
> ignore my input.  It just creates the object with bend sections that
> correspond to points in the path.

    Make your path using the top view or right view (i.e, all the points
aligned in the y-direction.  And why not make the path with lots of points?
You won't be rendering it, so it won't eat up time and memory.  The more
points you use, the smoother a curve you'll get.

>
> And it does two very annoying things.  The extrude is fine until it gets to
> the end of the path, then it flattens out (in the last section) and extends
> back to the beginning of the path so I get an final object that looks
> something like this:

    This is usually due to memory limtations, I believe.  How much RAM
do you have in your machine?  You can probably solve this problem by
reducing the number of sections you specify in the Extrude requester.

-John

John J. Humpal -- [e-mail] -- short .sig, std. disclaimer

##

Subject: Re:  animation trouble
Date: Mon, 9 Dec 91 14:19:30 EST
From: [e-mail] (Alan Price)

If you use the program 'display' by Hash Enterprises, it will play anims
that have a changing palette jsut fine. (It also has lots of nice keyboard
control and a visual frame-counter option.) This is for playing the 'anim'
or optcode 5 type anims and not the Imagine format. Unless you plan to
rearrange your frame order or do internal looping and want to change it
any time you wish, I suggest you are better off using the 'anim' format
as it takes much less disk-space and loads faster.

If you still feel the desire to know how to lock the palette, then always
render your frames in the 'rgbn' format. When you then select 'make' to
create an animation Imagine will ask 'lock palette?'. This is only in
the case of using 'rgbn' format and not 'ilbm'. Evidently, Imagine's
rgbn format leaves enough color information in each file to allow palette
shifts to match one another, or at least more easily than with ilbms.

Clarification: You select 'anim' format from within Imagine. You find
this in the 'Modify' requestor for the rendering subprojects. Imagine will
then build its anims in the anim optcode5 format for playback by many
available play programs.

AP.

##

Subject: Hinge
Date: Mon, 9 Dec 91 14:35:12 EST
From: [e-mail] (Alan Price)

Hinge can also be used to simply 'attach' an object to another.
Anywhere the first object goes, the other goes with.

Be careful when doing Mike C.'s example of an object orbiting a
planet. It will work fun unless you have the central planet revolving
on its own axis. The 'hinged' object will want to orient itself in
relation to the position of the planet and will therefore travel around
right along with the rotation. If you made a keyframe motion for the
object to orbit in the opposite direction of the planets rotation,
it would not go anywhere!

(editor's note: 'work fun' should read 'work fine'. But can be
considered interchangeable anyway.)
AP.

##

Subject: Re: Object instances in Imagine
Date: Mon, 09 Dec 91 15:10:08 EST
From: Mark Thompson <[e-mail]>

Steve Koren writes:
> Lets say that you build a house object. It ends up at over 120K when you
> save it on disk, not including the brushmaps.

> Lets say that Imagine allowed you make
> "Virtual Copies" of the house object.  The virtual copy, or "instance",
> would share the same vertex, edge, polygon, brushmap, attribute, etc.,
> data as the original.  There would be only one copy of this stuff.  Each
> instance would simply point to the same description.

I do not believe this is technically feasible as most renderers I know of
require that all the polygon data in a scene be available at render time.
In other words, all those pointers to existing objects would have to be
transformed into real view space polygons. So any savings that would be
made in the scene desription "file/structure" will be lost during actual
rendering. You therefore need that much memory for all those instances
of the house object. The only way around this is virtual memory which
can slow rendering down tremendously. To give you a feeling for why this is,
imagine that all the house objects have reflective exterior walls. How can
you calculate the reflections if all the polygons aren't loaded into
memory. The same holds true for hidden surface removal.

> It is definately technically sound, as it is
> a time-proven technique which has been employed by other 3D rendering
> programs.

I cannot claim to be familiar with every technique known for rendering
3D objects, but my guess is that whichever programs you are refering to,
you have misinterpreted the capabilities of the renderer. It is more likely
that the programs you speak of can build scenes using a hierachical
description (using multiple pointers to the same object database for
multiple instances) such as PHIGS does, and then during render time, the
polygons are all transformed and expanded out to a multi megabyte
scene. If you are truly certain this is not the case, I would like to hear
about it. But even if such rendering techniques existed, it would most likely
be a MAJOR rewrite of Imagine to implement it. You are better off just
buying more RAM.
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|      `       '        Mark Thompson                 CONCURRENT COMPUTER  |
| --==* RADIANT *==--   [e-mail]        Principal Graphics   |
|      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   |
|     Productions       [phone] [phone]   & General Nuisance   |
|                                                                          |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

##

Subject: Raydance
Date: Mon, 9 Dec 91 17:00:14 -0500
From: [e-mail] (BRANHAM,JOSEPH FRANKLIN)

(stepping off of the bounds of the mailing list)

I saw an ad for a script-based renderer called RayDance in the latest Avid.
(Well, the one with Mr. Worley's 2.0 article, anyway)

Has anyone gotten their demo disk? Is it freely distributable?

The software claims to support virtual objects and bump and texture WRAPPING.
It is also a script-based system, but if it had support for imagine .scene
files, it would be a wonderful investment.

(especially since it is put out by a company called Radiance Software--what
does THAT make you think of?)

Frank Branham

##

Subject: Re: Object instances in Imagine
Date: Mon, 9 Dec 91 17:46:07 MST
From: Steve Koren <[e-mail]>

> I do not believe this is technically feasible as most renderers I know of
> require that all the polygon data in a scene be available at render time.
> In other words, all those pointers to existing objects would have to be
> transformed into real view space polygons. So any savings that would be
> made in the scene desription "file/structure" will be lost during actual
> rendering.

Mark brings up a good point.  Actually there are several ways to implement
this idea.  You get to pick whether you want to optimize for speed or
memory usage.

One way is to perform a separate step before your main rendering in which
you create new objects in the positions of all of the instances.  This
incurs no extra performance penalty during actual rendering, but it does
incur the memory penalty as Mark points out above.

Another way is to just store the pointers, and resolve the true positions
of the instances dynamically at render time.  This is slower, but you save
boat-loads of memory.  Imagine might well do some of this now.  For
example, they may be storing the positions of points and edges relative to
the axis of that object.  (This makes rotations and transformations easy
since you don't have to visit each point in the object).  If that is so,
they are already doing similar transformations to find the true position
of things, and this method requires little extra work over that.  If they
aren't, then it would require more extra work for the transformations.
(But not all that much if you use bounding volumes and are dealing with
fairly small objects).

At any rate, having the _ability_ to do the transformations at render time
and avoid storing multiple objects doesn't _preclude_ you from resolving
each instance before you render if you so wish.  You just get to pick
which way you want to do it.  If you have boatloads of memory and want
quick rendering, you pick the first method.  If you have limited memory
and don't care as much about speed, you pick the second.  A few years ago
I developed a prototype 3D system which used the second method.  It was
slower than the first, but not as much as you'd expect, since the price of
all the other things that go on is large compared to the price of an
additional coordinate transformation.

As for how badly this affects the current Imagine code, I don't have much
of an idea since I've never seen it.  However, it might not be as bad as
it would at first appear.  For example, suppose they are picking a point's
position out of some sort of data structure for objects.  Now they just
have to pass it through a transformation function before they use it.  The
tricky part is to avoid doing this any more than necessary, which may or
may not get ugly depending on how the code is architected now.

  - steve

##

Subject: Re: 68000 bugs?
Date: Mon, 9 Dec 91 18:23:46 PST
From: "Jim Lange" <[e-mail]>

In-Reply-To: WRPYR:[e-mail]'s message of 12-08-91 23:31

I have also experienced bugs that I think are related to the integer version of
Imagine on a 68000 (A1000 in my case).

     o Envirironment reflection maps don't work.  I get grey "snow" on my
       objects.  This happens in scanline, trace, 24-bit, dithering on & off,
       EVERY mode.  You can still see the correct image underneath all the
       garbage.

     o Spherical and cylindrical color maps combined with bump maps.  Same as
       above--covered with white and grey specks.


-------------------------------------------------------------------------------
Jim Lange                [e-mail]
Oracle Corporation            {uunet,apple,hplabs}!oracle!jlange
-------------------------------------------------------------------------------

##

Subject: raydance
Date: Mon, 9 Dec 91 20:04:36 PST
From: [e-mail] (Kevin Kodama)

frank branham asks:
>i saw an ad for a script based renderer called raydance...

i downloaded the demo last night off of portal- it IS script based, and the
demo seems very interesting-nice rendering, esp. bumpmapping...
i'll investigate further...
kevink

##

Subject: Re: Object instances in Imagine
Date: Tue, 10 Dec 91 12:00:58 EST
From: Mark Thompson <[e-mail]>

Steve Koren writes:
> Another way is to just store the pointers, and resolve the true positions
> of the instances dynamically at render time.

I gave this some further thought last night and I could imagine an
implementation of such a method. It seems that there would be a great deal
of potential for memory thrashing for repeated loading and unloading of
objects over and over and redundant coordinate transformations. I am
refering to redundant operations on specific object instances (repeatedly
expanding the same pointer references). This would depend a great deal on
the scene. This would be particularly true for a ray caster where
interobject dependancies are important and can vary greatly even in a small
collection of rays. It would seem much less of a problem in a Z-buffered
scanline approach where each object could be rendered independant of the
others provided no shadow casting was involved. It could however slow down
the render time to some degree by preventing certain optimizations from
being performed efficiently.

> I developed a prototype 3D system which used the second method.

Good deal. Was it a tracer or scanline renderer?

> As for how badly this affects the current Imagine code, I don't have much
> of an idea.   Now they just
> have to pass it through a transformation function before they use it.  The
> tricky part is to avoid doing this any more than necessary, which may or
> may not get ugly depending on how the code is architected now.

For preventing too much of a speed penalty, this is definately where the
work lies. Some sort of object caching scheme might help out a bit.
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|      `       '        Mark Thompson                 CONCURRENT COMPUTER  |
| --==* RADIANT *==--   [e-mail]        Principal Graphics   |
|      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   |
|     Productions       [phone] [phone]   & General Nuisance   |
|                                                                          |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

##

Subject: Pixel 3-D 2.0 and phong/faceted
Date: Tue, 10 Dec 91 14:42:47 -0500
From: [e-mail] (Michael B. Comet)

    I just recieved mail from Mr. Worley after asking him a rather
mysterious question I had with regards to Imagine objects, and Pixel
3-D.

    It seems the phong shading on imagine actually works by having
double the amount of points for an object.  So, after you convert an
object from pixel 3-D, go into the detail editor, load and select your
object, and then use the menu function MERGE.  When this is done, phong
shading for object from pixel will work properly.

    This one had me very confused for quite some time.


    Hope this helps someone else out there!

                Mike C.
                [e-mail]

##

Subject: Pixel 3D?
Date: Tue, 10 Dec 91 15:27:28 CST
From: camelot![e-mail]

    I'm trying to model a human head with the intent of animating
    emotions into the facial features.  Other than the tools available
    to me in Imagine, I'm looking for other tools to enable me to
    create complexed models.  I've heard some noise about Pixel 3-D.
    What does it do?  Would it enable me build a model like a skulptor
    building a clay model?  I'd like to be able to mold the shape like
    I would with clay.  Adding some material here, deleting some
    there, until I build all of the facial features that I need.  Then
    I'd like to be able to modify the contours until I get every curve
    looking the way I want it too.  After that I want to modify the
    contours on the face and tween it showing the changing
    emotions.  What product would most be able to help me do this?

    Thanks,

    Dale



        ____________________________^__________________________________

        dale r. rogers               Email:  ingr!b24a!camelot!dale
                                     Internet:
                                     ingr!b24a!camelot![e-mail]

##

Subject: Re: 68000 bugs?
Date: Tue, 10 Dec 91 10:43:38 EST
From: [e-mail] (Bob Lindabury, SysAdm)

"Jim Lange" <rutgers!us.oracle.com!jlange> writes:

> I have also experienced bugs that I think are related to the integer version
> Imagine on a 68000 (A1000 in my case).
>
>      o Envirironment reflection maps don't work.  I get grey "snow" on my
>        objects.  This happens in scanline, trace, 24-bit, dithering on & off,
>        EVERY mode.  You can still see the correct image underneath all the
>        garbage.
>
>      o Spherical and cylindrical color maps combined with bump maps.  Same as
>        above--covered with white and grey specks.

Isn't this the infamous "digital bounce" syndrome that happens in
Imagine when you locate the map right on the objects surface?

You can try moving the map a point or so away from the objects
surface to make it work correctly I believe.

-- Bob

 The Graphics BBS  908/469-0049  "It's better than a sharp stick in the eye!"
 ============================================================================
  InterNet: [e-mail]                | Raven Enterprises
      UUCP: ...rutgers!bobsbox!graphics!bobl      | 25 Raven Avenue
    BitNet: bobl%graphics.rent.com@pucc           | Piscataway, NJ 08854
    Home #: 908/560-7353                          | 908/271-8878

##

Subject: CENTAUR Software's Imagine Tape direct to you... from HELL!
Date: 21 Mar 91 15:37:00 EST
From: "Mark D. Manes" <[e-mail]>

Warning Will Robinson... Danger, Warning!

Folks, I recently checked out the new Imagine video tape from Centaur
Software... in a word, I think it, well, sucked.

I hate to use words that strong, but the narration was terrible.  I
felt as though I was hearing stream of thought rather than a nice
presentation of the Imagine program.  Further after watching the
nearly 90 minute tutorial (yawn) the creation that I suffered
90 minutes to see was ugly to bone.

The tutorial seems to be disjointed and does not explore the
detail editor with any depth.  Further it breezes through the
description of adding faces to an object without ever really
showing you how to do it.  I about died when I watched the section
on the attributes requestor, the tape said things like the filter
gadget adjusts the filter settings!  Great, I could not have
guessed that.  :-)

I _have_ created many interesting pictures just from following the
tutorials in the Imagine manual!  This tape would be great if
they had simply recreated the tutorials that are in the manual,
instead of taking me on a disjointed chaotic trip through Imagine.

This tape should be avoided at all costs.

 -mark=

 +--------+   ==================================================
 | \/     |   Mark D. Manes   "Mr. AmigaVision,  The 32 bit guy"
 | /\  \/ |   [e-mail]
 |     /  |   [phone]    "Make up your own mind! - AMIGA"
 +--------+   ==================================================

##

Subject: Re: 68000 bugs?
Date: Tue, 10 Dec 91 17:15:52 PST
From: "Jim Lange" <[e-mail]>

Bob Lindabury <[e-mail]> writes:

>"Jim Lange" <rutgers!us.oracle.com!jlange> writes:
>
>> I have also experienced bugs that I think are related to the integer version
>> Imagine on a 68000 (A1000 in my case).
>>
>>     o Envirironment reflection maps don't work.  I get grey "snow" on my
>>       objects.  This happens in scanline, trace, 24-bit, dithering on & off,
>>       EVERY mode.  You can still see the correct image underneath all the
>>       garbage.
>>
>>     o Spherical and cylindrical color maps combined with bump maps.  Same as
>>       above--covered with white and grey specks.
>
>Isn't this the infamous "digital bounce" syndrome that happens in
>Imagine when you locate the map right on the objects surface?
>
>You can try moving the map a point or so away from the objects
>surface to make it work correctly I believe.

This was my first thought when I encountered this, but It only happens in the
wrap X/Z modes (i.e. not flat) and I have tried changing both axis location and
brush size (in local mode and confirming) to every conceivable extreme with the
same result.  Besides, how can an environment map (i.e. the brush name in the
globals requester) be oriented incorrectly?

-------------------------------------------------------------------------------
Jim Lange                [e-mail]
Oracle Corporation            {uunet,apple,hplabs}!oracle!jlange
-------------------------------------------------------------------------------

##

Subject: VCR for DCTV editing
Date: Tue, 10 Dec 91 21:15:29 -0500
From: [e-mail] (BRANHAM,JOSEPH FRANKLIN)

I'm looking for a good VCR to "string together" DCTV animations. The idea
is to play as much as I can fit in memory, then edit them out to tap

In other words, I'd like to be frame-accurate on editing, but don't need
a single-frame record.

I've been looking (drooling) over the Panasonic AG-1260. Is this overkill
for what I need? Just about right? Or will I be very unhappy at the results?

Would happily beg any suggestions from those in the know.

Moo
Frank Branham

##

Subject: Re: Pixel 3D?
Date: Wed, 11 Dec 91 10:49:02 EST
From: Mark Thompson <[e-mail]>

> I'm trying to model a human head with the intent of animating
> emotions into the facial features. I've heard some noise about Pixel 3-D.
> What does it do?  Would it enable me build a model like a skulptor
> building a clay model?  What product would most be able to help me do this?

Could I reccommend Alias Animator. It would only cost about $20K if you
buy an SGI Indigo..... I didn't think so. Alias produces perhaps one of the
finest modelers in existance but it is not cheap.

Pixel 3D 2.0, while being an outstanding tool for many modeling tasks
is not geared toward what you are talking about. The only products that come
to mind when you refer to smoothly sculpting 3D models of heads and the
like are Hash's Animation Journeyman and an upcoming product Axiom (the
makers of Pixel 3D) called Polyform. Here is a blurb on it extracted from
the net:
       "I talked to Axiom software today about upgrading my Pixel 3D 1.1
to the new 2.0 version. The upgrade fee is $45 with the first page of the
old manual. The new version is really nice, I can't wait to get it.
        Anyways, I was speaking to them about future products. They are in
the process of writing/completing a package called POLYFORM that is going
to be a high end modeler. It will be in the $300 to $500 price range, with
no planned upgrade from Pixel 3D (undecided as of yet.)
        This POLYFORM package is supposed to do everything that PIXEL 3D 2.0
does and more. It will currently take three bitmap views of an object and
make it in to an object. This is currently working! I am impressed since I
don't think anybody else is doing this on a personal computer or low end
workstations.
        This product is due sometime in spring or summer of '92. It is
supposed to be the most advanced modeler on any platform."
                                                   Juan Trevino

|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|      `       '        Mark Thompson                 CONCURRENT COMPUTER  |
| --==* RADIANT *==--   [e-mail]        Principal Graphics   |
|      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   |
|     Productions       [phone] [phone]   & General Nuisance   |
|                                                                          |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

##

Subject: Re: Pixel 3-D 2.0 and phong/faceted
Date: Wed, 11 Dec 91 11:06:30 EST
From: Mark Thompson <[e-mail]>

>     It seems the phong shading on imagine actually works by having
> double the amount of points for an object.  So, after you convert an
> object from pixel 3-D, go into the detail editor, load and select your
> object, and then use the menu function MERGE.  When this is done, phong
> shading for object from pixel will work properly.

Phong shading works by interpolating normal vectors that are produced at
each polygon vertex by averaging the surface normals of all adjacent
polygons. If the adjacent polygons do not share the same vertices, then
the normals are unaffected.
           ..                  .
          /  \                / \
         /    \              /   \
  will not be smoothed   will be smoothed

In the first case, even if the two vertices are on top of one another,
the normals will NOT be uneffected. Once MERGE is used, the second case will
result which can be interpolated (smoothed). This can be used to you
advantage when several abutting surafce are to be smoothed, but the point
of actual abuttment (is that a word?) is to be a hard edge. This istypically
the case with beveled face logos.
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|      `       '        Mark Thompson                 CONCURRENT COMPUTER  |
| --==* RADIANT *==--   [e-mail]        Principal Graphics   |
|      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   |
|     Productions       [phone] [phone]   & General Nuisance   |
|                                                                          |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

##

Subject: rendering fonts
Date: Wed, 11 Dec 91 21:38:27 EST
From: [e-mail] (Dan Drake)

Has anyone else tried to render some of the characters that were
uploaded to hubcap?  I'm talking/writing about the Tex Roman font.

Basically, I can't even get one letter to render.  I can see it in the quadview
mode, but when I render a frame, all of the letters disappear.  My stage
consists of two lights, and the letter n.  I have substituted other objects
for the n, and they render fine.  Is it that I don't have enough memory and
imagine deletes objects so it can render a scene?  I have rendered the space
station with no problem and that is way bigger then any of the characters.
I have a six meg A3000, so I didn't think that I would hit this problem with
so few objects.

thanks,

dan.

##

Subject: Re: animation trouble
Date: Wed, 11 Dec 91 00:03:14 GMT
From: mit-eddie!bknight.jpr.com!yury (Yury German)

:
:> I am trying to make a simple animation but the outputed pictures have
:> different palletes.  I don't know why its happening to me, I have tried
:> low res and ham and I get different pallete for pictures.  I remember
:> once imagine asked me if I wanted to lock the pallete, but it never
:> asked me that again.
Well the easiest way is to render as is... then bring it into Art
Departement Pro and lock the pallette there once you compute it. Then any
picture you bring in will have a locked pallete. This will also work with
most other programs including a few shareware programs.

##

Subject: Strange checks texture
Date: Wed, 11 Dec 91 12:09:08 CST
From: [e-mail] (Michael Linton)

Something strange happens when I render the checks texture especially on
a flat plane.  Large chunky dithering appears all over the object, and it
is not shading.  Large black specks appear all over the checkered plane,
and the checks themselves are screwed up.  I thought maybe my checks
texture was perhaps corrupt, so I re-copied it on to my HDD, and it still
did the same thing.  This has never happend in the past. Does anyone know
what might be the problem?

         Thanks.


--- (Michael Linton) a user of sys6626, running waffle 1.64
E-mail: [e-mail]
system 6626: 63 point west drive, winnipeg manitoba canada R3T 5G8

##

Subject: Experimental?
Date: Wed, 11 Dec 91 23:04:03 PST
From: Daryl T. Bartley <[e-mail]>

Just a quick question, is the PICTURES/EXPERIMENTAL dir on hubcap still usable?
I had some suspect pics, and was thinking about putting them there, rather than
trying for a handwaving explanation of the scene, etc. But with the storage
problem at hubcap, is it still "ok" to put stuff there?


Daryl Bartley
[e-mail]

##

Subject: Re: Strange checks texture
Date: Thu, 12 Dec 91 7:21:49 MST
From: Steve Koren <[e-mail]>

> Something strange happens when I render the checks texture especially on
> a flat plane.  Large chunky dithering appears all over the object, and it
> is not shading.  Large black specks appear all over the checkered plane,
> and the checks themselves are screwed up.  I thought maybe my checks

> did the same thing.  This has never happend in the past. Does anyone know
> what might be the problem?

I betcha that your checks texture lies exactly on the plane of the surface
you are trying to texture.

Try moving it off the surface by, say, -0.5 units in the texture-axis Y
direction, and then making sure the Y axis extends *through* the surface.
Due to the way Imagine renders textures, they sometimes don't work well if
they are exactly on the surface.  I had that trouble at first also, but
all the textures work fine for me now.

Good luck,

   - steve

##

Subject: Re: rendering fonts
Date: Thu, 12 Dec 91 12:12:27 EST
From: [e-mail] (John J Humpal)

If this is stupid question, I apologize in advance, but have you checked
the ATTRIBUTES of the letter to make sure transparency isn't turned all
the way up?  Also, is the letter within your world in the stage editor.
Stage defaults to a 1024x1024x1024 world size, and if your object(s) fall
outside that range, they will not render in trace mode.

Again, I apologize if these things have already been taken into consideration.

-John

John J. Humpal -- [e-mail] -- short .sig, std. disclaimer


##

Subject: Re: Experimental?
Date: Thu, 12 Dec 91 18:38:03 EDT
From: [e-mail] (Doug Dyer)

>
> Just a quick question, is the PICTURES/EXPERIMENTAL dir on hubcap still usable?
> I had some suspect pics, and was thinking about putting them there, rather than
> trying for a handwaving explanation of the scene, etc. But with the storage
> problem at hubcap, is it still "ok" to put stuff there?
>
>
> Daryl Bartley
> [e-mail]
>
>
>
The store problem on hubcap is a voluntary "remove your picture after so
long - everyone has had a chance to see it - type of deal "

I removed that directory because it fell in that category and noone was
using it.  Please feel free to upload pictures.. give 'em a month or so,
and delete them.  That way, space will never be a problem and people can
upload new stuff.


Thanx!
Doug


--------------------------------------------------------------------------
Doug Dyer     *      Clemson University     *     [e-mail]
Quote 'O Fun: DOS is a bike without the seat.           skydive naked
--------------------------------------------------------------------------

##

Subject: Non-rendering fonts
Date: Thu, 12 Dec 91 18:50:02 EST
From: [e-mail]

I haven't used the fonts on hubcap (I use Glenn Lewis' TSTeX to output
3D text, works great!) but the biggest check is to make sure there
are faces in your object. You could, for some bizarre reason, only
have points and edges (which would look great in a wireframe) but
no faces. In Detail, pick your letter and go into "pick faces" mode.
Use "select next" (rt-amiga-n) a few hundred times.. you should see the
faces highlight in orange in order. If you don't see the faces highlight,
there are no faces in the object and that's the reason its dying.

Actually, you could just use the "find requester" and look at the statistics
to see the # of faces.

Anyway, as you said, its the simple things that make things break. If
there are faces, and they aren't transparent, and they aren't rendering
in scanline mode when you have enough RAM, it looks like an Imagine
bug. If so, tell me and I'll D/L the objects and check.

-Steve

---------------------------------------------------------------------------
Steve Worley                                        [e-mail]
---------------------------------------------------------------------------